This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] posix: Remove dynamic memory allocation from execl{e,p}
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Joseph Myers <joseph at codesourcery dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 29 Jan 2016 15:39:33 -0200
- Subject: Re: [PATCH] posix: Remove dynamic memory allocation from execl{e,p}
- Authentication-results: sourceware.org; auth=none
- References: <1454075599-2304-1-git-send-email-adhemerval dot zanella at linaro dot org> <56AB6FFF dot 7040308 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1601291541490 dot 29026 at digraph dot polyomino dot org dot uk>
On 29-01-2016 13:43, Joseph Myers wrote:
> On Fri, 29 Jan 2016, Florian Weimer wrote:
>
>> I would rather see a variant of struct scratch_buffer which uses mmap
>> for the fallback allocation, and use it here, rather than imposing
>> arbitrary limits. It's not clear to me at all if __MAX_ALLOCA_CUTOFF is
>
> Agreed. glibc functions should avoid arbitrary limits, which means they
> should not fail simply because the limit for stack allocation was
> exceeded.
>
> (This does mean the functions need to do deallocation of the memory
> allocated with mmap, if the underlying execve fails.)
>
The problem is the constraint associated with the functions where only
stack allocation make sense. For all exec function family, where they
can be called either through a signal handler or in vfork child, we
can not really on dynamic memory allocation (either through malloc or
directly by mmap).
And I also see that __MAX_ALLOCA_CUTOFF is a limit that does not make
any sense in this context: it is just an arbitrary value that will
potentially limit the total function usability (total number of
arguments). It also won't prevent stack overflow, since the call
can be deeply nested and an allocation smaller than __MAX_ALLOCA_CUTOFF
can trigger the overflow.
My view is for such function is just try to allocate the buffer on
stack and allow it fails through invalid access in case of buffer
overflow.