Re: why Glibc does not build with clang?

[OndÅej BÃlka <neleai at seznam dot cz>]

On Fri, May 16, 2014 at 02:44:22PM +0200, Florian Weimer wrote:
> On 05/16/2014 02:37 PM, Will Newton wrote:
> 
> >I'm curious as to why you want to get rid of alloca?
> 
> There's no explicit checking if the stack has room for the requested
> size.  It is not always clear if the implied length check through
> the explicit guard page prevents deliberate misuse of such alloca
> failures for nefarious purposes.  So we risk having crashes (already
> quite bad) and often cannot rule out any further security impact
> beyond the crash (worse).
> 
> Same thing applies to VLAs on the stack, obviously.
> 
> GCC could provide fairly cheap instrumentation (both in terms of
> code size and execution speed) that turns alloca failures (and
> too-large VLas) into reliable crashes, but that GCC feature is
> currently somewhat broken and not usable at all.
> 
All you need is reliable way to get stack boundaries. I proposed to add
these some time ago. It would make alloca failures reliable without
need of gcc support.

A better alternative than ten line boilerplate alloca with fallback to malloc 
would be using malloca, that handles these automatically. With stack
bounds it could allocate fairly safely, without these it must resort to
heuristic like size is less than 65536.

A sample implementation is here, I ommited a returned malloc that takes
care of free, now it could be done with a __destructor attribute but it
needs a header for each function that uses malloca.

__thread void *stack_cur;
__thread void *stack_start;
__thread size_t stack_size;

/* for simplicity stack grows upwards, reverse signs in downward case. */
#define malloca(size) ({ \
  if (stack_cur + size < stack_start + stack_size / 2
      && stack_cur > stack_cur + stack_size  /* overflow */
      && stack_start < stack_cur && stack_cur < stack_start + stack_size /* for signals. */
    alloca (size);
  else
    returned_malloc(size);
})