This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Don't bind to registered ports in bindresvport
On 6/6/2012 4:51 PM, Roland McGrath wrote:
>> Using alloca can create a security risk by putting the buffer in
>> in the same location every time relative to the stack pointer or
>> call sequence. While with malloc the allocation locations can be
>> random.
>
> This kind of rationale is a very generic one. Throughout libc, we
> have decided that using alloca (or VLAs) is the appropriate thing to
> do because of the performance benefit despite this kind of concern.
> (It's also the case that for reasonably small sizes alloca can "never"
> fail--i.e. the only way it can fail is a stack-extending page fault
> that cannot be serviced, crashing the program--while using malloc
> requires handling the ENOMEM case explicitly.) There is always a
> trade-off between performance and "hardening" and other such concerns.
> I think we should be more systematic about this than simply going with
> the preference of whoever happens to be writing or reviewing the code.
>
> This particular case is one where the interface is not at all
> performance-sensitive (if it were, even considering having it call NSS
> modules and such things would be entirely out of the question--as it
> stands, I just think it's quite dubious, but others feel differently)
> and the API doesn't make it particularly difficult to fail gracefully
> for the ENOMEM case. So that may be good reason to choose malloc over
> alloca here. It's probably right that the decision should be made
> case-by-case considering these sorts of issues. But I don't think the
> decision should ever be ad hoc like this.
>
> The existing standard is that using alloca in libc is always fine,
> given appropriate use of the size-cutoff macros. Before objecting to
> use of alloca is considered a valid reason to reject a libc change,
> we need to have a clear and systematic policy about how the decision
> is made.
You make a very good point.
First draft:
http://sourceware.org/glibc/wiki/Style_and_Conventions#Alloca_vs._Malloc
Cheers,
Carlos.
--
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026