This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/2][BZ #12416] Use stack boundaries from /proc/PID/mapsto make stack executable


On Wed, 25 Apr 2012 13:34:24 -0700 (PDT), Roland wrote:
> > Using __libc_stack_end as the end of stack to mark an executable
> > stack misses pages at the end of stack that are used to store
> > program arguments, environment variables and auxiliary elf
> > information.
> 
> This actually seems desireable to me.  If there are additional whole
> pages of arguments et al, those pages don't need to be executable, so
> why make them so?

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.

> Perhaps it should work in a different way.  It's nasty to
> require /proc access, and all the io plus stdio overhead et al might
> make it more costly than another method.  It could use something like
> the mprotect-probing technique to locate the hole below the stack
> that linux/dl-execstack.c uses when PROT_GROWSDOWN is not available.

Thanks, I think I will do this.
 
> 1. Just cache the past results and apply them as upper/lower bounds
> so that you never return a smaller size later.

The proc traversal will be needed only once per execution because one
would only need to mark the stack executable once. The only place where
repeat traversals would be required (and a cache useful) are due to
calls to pthread_getattr_np() and that is unavoidable since we still
need the top of stack, which may keep changing.
 
> 2. Treat contiguous mappings below the stack all as part of the stack.

This is doable, but I prefer your earlier idea of trying to find the
hole below the stack and then using that as the stack end.

> This is unconditionally adding Linux-specific code to the test, which
> is not acceptable.  It also fails to check the return value of sscanf,
> and should use '!= NULL' rather than implicit boolean coercion.
> 
> Why test at this level, anyway?  The bug is that the execstack switch
> makes pthread_getattr_np give inconsistent results.  So just test that
> pthread_getattr_np gives the same results before and after the switch.

OK, I'll write a separate test case with pthread_getattr_np for this.

Thanks,
Siddhesh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]