[PATCH 2/2][BZ #12416] Use stack boundaries from /proc/PID/maps to make stack executable

[Siddhesh Poyarekar]

On Mon,  7 May 2012 13:02:21 -0700 (PDT), Roland wrote:
> 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 mean.
> 

I was talking about mm->vm_stack that accounts for all vmas allocated
with MAP_GROWS*. But I'm wrong anyway, since that accounting is not
affected by vma splits, since the vmas still remain MAP_GROWS*.

So I propose the following simpler patch instead in the interest of
marking as less of the stack as possible as executable. The patch
modifies pthread_getattr_np to use the page end containing
__libc_stack_end as the end of stack and hence return stack_size and
stack_end + stack_size as the size and address of stack respectively.

One other thing I realized when I wrote the test case is that
__pthread_attr_getstackaddr simply subtracts stacksize from stackaddr
and returns it, which is wrong for architectures with _STACK_GROWS_UP.
In fact, pthread_getattr_np also probably has a similar problem. I am
currently surrounded by x86 boxes, so I'll see if I find myself an ia64
box to confirm this. I'll post patches for those problems separately if
they're applicable.

Regards,
Siddhesh


ChangeLog:
2012-05-08  Siddhesh Poyarekar  <siddhesh@redhat.com>

	* elf/tst-execstack.c (do_test): Adjust test case to ensure that
	pthread_getattr_np behaviour remains the same after marking
	stack executable.

nptl/ChangeLog
2012-05-08  Siddhesh Poyarekar  <siddhesh@redhat.com>

	* nptl/pthread_getattr_np.c (pthread_getattr_np): Use
	__libc_stack_end rounded to the end of containing page as the
	real stack end.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: glibc-execstack.patch
Type: text/x-patch
Size: 3721 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120508/88367df9/attachment.bin>