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

Siddhesh Poyarekar siddhesh@redhat.com
Tue May 15 02:45:00 GMT 2012


On Mon, 14 May 2012 16:46:22 -0700 (PDT), Roland wrote:
> I don't think it's reliable to use __builtin_frame_address with a
> nonzero argument, depending on optimization behavior and such.
> 
> Why don't you just use #if _STACK_GROWS_{DOWN,UP} here?

The macro is defined only within the glibc sources in stackinfo.h. I
reckoned that test cases should be using only publicly available
interfaces within glibc, which is why I wrote this instead. Is it OK
to use stackinfo.h here?
 
> This says we're not checking them separately but doesn't really say
> why, or at least not clearly enough for me.  If it's really the case
> that the two could change such that their sum/difference remains the
> same and that would be kosher, then explain it more thoroughly.  If
> not, then just check them separately.

It is possible that the dlopen'd module may have been mmapped just
above the stack. The stack size is taken as MIN(stack rlimit size, end
of last vma) in pthread_getattr_np, so it is possible that the size
may have changed as a result if the rlimit is set high enough.

A subsequent call to pthread_attr_getstack returns the size and
(bottom - size) as the stacksize and stackaddr respectively. Due to the
above it is clear that if size changes due to the new mapping, then both
stacksize and stackaddr can change, but the stack bottom should remain
the same, which is nothing but stackaddr + stacksize.

Regards,
Siddhesh



More information about the Libc-alpha mailing list