This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 2/2][BZ #12416] Use stack boundaries from /proc/PID/mapsto make stack executable
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 7 May 2012 13:02:21 -0700 (PDT)
- Subject: Re: [PATCH 2/2][BZ #12416] Use stack boundaries from /proc/PID/mapsto make stack executable
- References: <20120419120021.4780e8c8@spoyarek><20120425203424.A744A2C0CA@topped-with-meat.com><20120426123653.765f1462@spoyarek><20120504231020.AF7C92C093@topped-with-meat.com><20120507084337.6d1ea127@spoyarek>
> So would you prefer a fix that does this instead, i.e. just use
> __libc_stack_end as the end of stack all the time?
I don't have an overwhelmingly strong opinion. But all else being equal,
my preference is to minimize the pages which are made executable. There's
no need for executability in the argument pages, so the security-paranoid
sort of conservatism says not to make them executable. But the truly
paranoid will eschew any DSOs that require it at all anyway.
> I personally prefer my earlier approach where we don't split the stack
> vma. I believe some aspects of the kernel stack accounting also relies on
> the stack vma, shown by the fact that the split vma does not show up with
> [stack]. This probably should be fixed in the kernel, but we're breaking
> that when we could do this in an alternate way.
What "kernel stack accounting" are you talking about? The [...] monikers
for /proc/PID/maps output are just meant to be vaguely informative in a
minimal-best-effort sort of way and should not be construed as signs of
anything deeper AFAIK. If you think there is some concrete sense in which
the kernel purports to grok what is and isn't part of your stack and let
that affect its behavior in any particular way, be explicit about what you