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] posix: Remove dynamic memory allocation from execl{e,p}



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.


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