This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2][BZ #12416] Use stack boundaries from /proc/PID/mapsto make stack executable
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 7 May 2012 08:43:37 +0530
- 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>
On Fri, 4 May 2012 16:10:20 -0700 (PDT), Roland wrote:
> > One reason is that execstack programs set up by the kernel look
> > different. This is probably just a cosmetic inconsistency, but it
> > is an inconsistency nevertheless. If that is acceptable then we
> > could just make pthread_getattr_np return __libc_stack_end rounded
> > up to page size as the end of stack rather than the real vma end.
>
> I think that's fine. A program that started with its stack
> executable is in fact different from one that loaded a DSO requiring
> executable stack.
>
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 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.
--
Siddhesh