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

[Roland McGrath <roland at hack dot frob dot com>]

> 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.


Thanks,
Roland