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: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Mon, 11 Jun 2012 17:14:35 -0400
- 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> <20120507200221.963992C099@topped-with-meat.com><20120508161750.063e9791@spoyarek> <20120514234622.30D472C09E@topped-with-meat.com><20120515081610.1b4aee17@spoyarek> <20120515163033.CD04B2C08B@topped-with-meat.com><20120516123338.55cd9a34@spoyarek>
On Wed, May 16, 2012 at 3:03 AM, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
> On Tue, 15 May 2012 09:30:33 -0700 (PDT), Roland wrote:
>> Do you mean just below the stack (lower address)? ?If it's actually
>> the dlopen'd module, then that is a file mapping rather than an
>> anonymous mapping like the stack. ?You can distinguish those in
>> /proc/self/maps (the fourth column is 00:00 for anonymous mappings and
>> not that for file mappings). ?So pthread_getattr_np need never be
>> confused by that case.
>
> Yes I meant below, sorry about that.
>
> I interpreted the pthread_getattr_np logic to consider the end of
> previous vma for stack size to mean that we're looking at the potential
> for the stack to grow, subject to rlimit. Whether or not the mapping
> above is anonymous should not matter in that case. If we consider that
> the file mapping happens below the stack, the potential for growth of
> the stack changes to the end of that mapping and if rlimit is high
> enough, it will change the stacksize and stackaddr returned.
>
> I've attached an updated patch with the rest of the changes. If we
> don't want to account for a too high rlimit (that is a pre-requisite
> for this situation to occur) then I can change the check to individual
> verification of stack size and stack address and send an updated patch.
>
> Thanks,
> Siddhesh
>
> ChangeLog:
>
> 2012-05-16 ?Siddhesh Poyarekar ?<siddhesh@redhat.com>
>
> ? ? ? ?* elf/tst-execstack.c: Include stackinfo.h.
> ? ? ? ?(do_test): Adjust test case to ensure that pthread_getattr_np
> ? ? ? ?behaviour remains the same after marking stack executable.
>
> nptl/ChangeLog:
>
> 2012-05-16 ?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.
Sorry for the long delay.
I received a complains against this change from ruby folks. Because of,
ruby interpreter show special error message when stack overflow is
detected. and they assume "stackaddr - stacksize" point to stack edge.
But this patch only changed stackaddr. thus the assuption broke.
Is there any chance to change stacksize too?