Re: [PATCH] Don't bind to registered ports in bindresvport

[Carlos O'Donell <carlos_odonell at mentor dot com>]

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