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

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

On 6/7/2012 4:10 AM, Paul Eggert wrote:
> On 06/06/2012 05:49 PM, Carlos O'Donell wrote:
>>  * What is stored in the alloca'd space? Is there a security issue
>>  inherent in placing this information at a known offset from the
>>  stack pointer? If there is then it might call for using malloc.
> 
> There is always a security issue in accessing memory, regardless of
> whether one uses alloca or simply takes the address of a local
> variable.  So I'm not sure why we're picking on alloca here.
> 
>>  * Is the allocated space large? The use of alloca in glibc is
>>  limited and large allocations will need to be taken from malloc.
> 
> __libc_use_alloca does that.
> 
> Here is a quick cut at a proposed revised draft.

Your proposed draft is excellent, and a considerable improvement
over my initial draft.

I've moved your revised draft into the portal and after review
I consider it a good final version.

Please review the wiki to ensure correctness in copying:
http://sourceware.org/glibc/wiki/Style_and_Conventions#Alloca_vs._Malloc

I revised the wording slightly here"
~~~
  This use of alloca is a memory optimization.  That is, the above 
{{{alloca}}} example is almost equivalent to the following:
{{{
    struct foo buffer[__MAX_ALLOCA_CUTOFF / sizeof (struct foo)];
    bool use_auto = bufsize <= sizeof buffer;
    struct foo *buf = use_auto ? buffer : malloc (bufsize);
    do_work_with (buf, bufsize);
    if (! use_auto)
      free (buf);
}}}
  except that the {{{alloca}}} version consumes only the stack space 
needed, rather than always consuming approximately {{{__MAX_ALLOCA_CUTOFF}}} 
bytes. Note that this isn't quite equivalent to the previous example 
because {{{__libc_use_alloca}}} limits alloca to {{{PTHREAD_STACK_MIN/4}}} 
(which may be bigger than {{{__MAX_ALLOCA_CUTOFF}}}) or 
{{{<thread stack size>/4}}}, the latter having a maximum bound 
of {{{__MAX_ALLOCA_CUTOFF}}}.
~~~

In truth I find the logic in glibc for __libc_use_alloca to be
broken for large PTHREAD_STACK_MIN sizes.

Say your PTHREAD_STACK_MIN is > 4*__MAX_ALLOCA_CUTOFF (no such
machine currently exists, at most IA64 is 196k or ~3*__MAX_ALLOCA_CUTOFF), 
say 8*__MAX_ALLOCA_CUTOFF.

Allocations between 1 -> PTHREAD_STACK_MIN/4 or 2*__MAX_ALLOCA_CUTOFF
succeed without any problem.

However, as soon as you allocate PTHREAD_STACK_MIN/4+1 bytes or 
2*__MAX_ALLOCA_CUTOFF+1 bytes then the maximum allocation is clamped 
down to __MAX_ALLOCA_CUTOFF? That's seems unintuitive to say the least.
Note that it will almost surely clamp to __MAX_ALLOCA_CUTOFF
because a default stackblock for most machines is on the order of
megabytes (2MB min, so 2MB/4 = 512kb > 64kb).

Thankfully no target has PTHREAD_STACK_MIN > 4*__MAX_ALOCA_CUTOFF, 
and allocations in that case proceed smoothly from:
1 -> PTHREAD_STACK_MIN/4 < __MAX_ALLOCA_CUTOFF,
up to __MAX_ALLOCA_CUTOFF, at which point you can't allocate more.

Did I read the code wrong?

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026