This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Use malloca instead alloca


On Wed, Jan 09, 2013 at 05:59:45PM +0100, Florian Weimer wrote:
> Anyway, to clarify, I'm not interested in enabling split stacks per
> se.  But the split stack support records the stack boundary in a TLS
> variable, and __builtin_alloca could use that to check (reasonably

OK, that makes sense. I still don't think it's useful however because
the "use as much as we have available" idiom is broken.

> >Honestly, my recommendation would be to ban use of alloca and VLA
> >entirely and replace them by small fixed-size arrays (like 256-1024
> >bytes depending on the expected usage), and simply call malloc when
> >the need is greater than the fixed size. This makes the free logic
> >easy (if (ptr!=fixed_buf) free(ptr);) and reduces the code size and
> >improves performance in the common cases (since the compiler can
> >generate better, simpler code when it does not need to do the
> >frame-pointer-like logic for managing dynamic-size allocations on the
> >stack.
> 
> As long as there's alloca, developers will use it.  It's quite
> popular even in new code.

Application developers can use it, but a particular project libc glibc
can impose a policy that it's not allowed in that project's code.

> I suspect it's not just the performance
> aspect, the implicit free() is likely a factor, too.

Implicit free does not help if you have to have an alternate case for
using malloc on large allocations. And performance is worse than the
fixed-size automatic array approach I described due to frame pointer
management.

> I'm not sure if we can change this preference, at least until we
> have conservative garbage collection as part of libc (so that heap
> allocation and stack allocation are equally simple).

Conservative GC is not the solution for that. If you're talking about
libc-internal memory usage, the simplest/cleanest solution would be
something like talloc where a single cleanup call before returning
from libc to the caller can free either (1) all memory allocated as
part of the work in libc-space, or (2) only temp working memory
that was allocated. This would make both success and error returns
trivial to handle.

All conservative GC would do is add lots of complexity and vulns where
memory fails to be freed under attacker-controlled conditions.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]