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