why Glibc does not build with clang?
diff mbox

Message ID 20140516225608.GA17863@domone.podge
State New
Headers show

Commit Message

Ondřej Bílka May 16, 2014, 10:56 p.m. UTC
On Fri, May 16, 2014 at 05:32:00PM -0400, Rich Felker wrote:
> On Fri, May 16, 2014 at 10:31:40PM +0200, Ondřej Bílka wrote:
> > On Fri, May 16, 2014 at 03:05:04PM -0400, Rich Felker wrote:
> > > On Fri, May 16, 2014 at 03:53:04PM +0200, Ondřej Bílka wrote:
> > > > 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.
> > > 
> > > The cost of a function call to look up the current stack boundaries
> > > (or a TLS access to get that info on some archs where TLS access is
> > > expensive) defeats much of the purpose of using alloca.
> > >
> > Oh really? It does not follow malloc also needs tls so you will always
> > be faster.
> 
> If TLS is the dominating factor (think old MIPS where the instruction
> to read the TLS register traps and gets emulated by the kernel), it
> brings the cost of alloca up on par with malloc, no?
>
It does but question is if it will be enabled.

> > Also you could avoid that check most times by checking
> > request if you crosses page boundary or creating lookup table which page 
> > belongs to which tread.
> 
> Perhaps, but this gets to be a lot more overhead/complexity for little
> if any demonstrable gain.
>
If there is little gain then you do not have to worry about performance
degradation in first place.
 
> > > Moreover, turning alloca failures into "reliable crashes" is not a
> > > solution. If an operation requires allocation which could fail, it
> > > must be able to back out whatever work it already did and report
> > > failure. Crashing is not an acceptable implementation.
> > > 
> > No, when it is third party codebase and it does not want to rewrite
> > existing code do you have a better proposal?
> 
> I was talking about internal usage of alloca in glibc. I don't think
> glibc can fix use in third-party software.
> 
I was not talking about glibc, I was saying how to fix alloca in general.
This could make check reliably any alloca in system if you recompile
binaries.

Enabling that from glibc is technically easy, apply following patch.
It is feasible to add this with some sort of configure option.

Comments

Rich Felker May 16, 2014, 11:20 p.m. UTC | #1
On Sat, May 17, 2014 at 12:56:08AM +0200, Ondřej Bílka wrote:
> > > > The cost of a function call to look up the current stack boundaries
> > > > (or a TLS access to get that info on some archs where TLS access is
> > > > expensive) defeats much of the purpose of using alloca.
> > > >
> > > Oh really? It does not follow malloc also needs tls so you will always
> > > be faster.
> > 
> > If TLS is the dominating factor (think old MIPS where the instruction
> > to read the TLS register traps and gets emulated by the kernel), it
> > brings the cost of alloca up on par with malloc, no?
> >
> It does but question is if it will be enabled.
> 
> > > Also you could avoid that check most times by checking
> > > request if you crosses page boundary or creating lookup table which page 
> > > belongs to which tread.
> > 
> > Perhaps, but this gets to be a lot more overhead/complexity for little
> > if any demonstrable gain.
> >
> If there is little gain then you do not have to worry about performance
> degradation in first place.

Obviously originally there was a performance benefit to alloca. The
"little demonstrable gain" was referring to the situation where you've
already made alloca costly (possibly on par with malloc) to deal with
its other flaws.

> > > > Moreover, turning alloca failures into "reliable crashes" is not a
> > > > solution. If an operation requires allocation which could fail, it
> > > > must be able to back out whatever work it already did and report
> > > > failure. Crashing is not an acceptable implementation.
> > > > 
> > > No, when it is third party codebase and it does not want to rewrite
> > > existing code do you have a better proposal?
> > 
> > I was talking about internal usage of alloca in glibc. I don't think
> > glibc can fix use in third-party software.
> > 
> I was not talking about glibc, I was saying how to fix alloca in general.
> This could make check reliably any alloca in system if you recompile
> binaries.

Supposedly GCC already has an option to reliably crash (when expanding
the stack by more than a page, write at least one byte to each page,
in order). I have not teasted it heavily though.

Rich
Ondřej Bílka May 16, 2014, 11:56 p.m. UTC | #2
On Fri, May 16, 2014 at 07:20:20PM -0400, Rich Felker wrote:
> On Sat, May 17, 2014 at 12:56:08AM +0200, Ondřej Bílka wrote:
> > > > > The cost of a function call to look up the current stack boundaries
> > > > > (or a TLS access to get that info on some archs where TLS access is
> > > > > expensive) defeats much of the purpose of using alloca.
> > > > >
> > > > Oh really? It does not follow malloc also needs tls so you will always
> > > > be faster.
> > > 
> > > If TLS is the dominating factor (think old MIPS where the instruction
> > > to read the TLS register traps and gets emulated by the kernel), it
> > > brings the cost of alloca up on par with malloc, no?
> > >
> > It does but question is if it will be enabled.
> > 
> > > > Also you could avoid that check most times by checking
> > > > request if you crosses page boundary or creating lookup table which page 
> > > > belongs to which tread.
> > > 
> > > Perhaps, but this gets to be a lot more overhead/complexity for little
> > > if any demonstrable gain.
> > >
> > If there is little gain then you do not have to worry about performance
> > degradation in first place.
> 
> Obviously originally there was a performance benefit to alloca. The
> "little demonstrable gain" was referring to the situation where you've
> already made alloca costly (possibly on par with malloc) to deal with
> its other flaws.
>
> > > > > Moreover, turning alloca failures into "reliable crashes" is not a
> > > > > solution. If an operation requires allocation which could fail, it
> > > > > must be able to back out whatever work it already did and report
> > > > > failure. Crashing is not an acceptable implementation.
> > > > > 
> > > > No, when it is third party codebase and it does not want to rewrite
> > > > existing code do you have a better proposal?
> > > 
> > > I was talking about internal usage of alloca in glibc. I don't think
> > > glibc can fix use in third-party software.
> > > 
> > I was not talking about glibc, I was saying how to fix alloca in general.
> > This could make check reliably any alloca in system if you recompile
> > binaries.
> 
> Supposedly GCC already has an option to reliably crash (when expanding
> the stack by more than a page, write at least one byte to each page,
> in order). I have not teasted it heavily though.
> 
Also alternative but I mentioned this as easy consequence of having stack
boundaries. Main aim is to switch for heap allocation when you do not
have enough stack space.

I was not sure if you could do this conversion or not as user could
check that.

Patch
diff mbox

diff --git a/stdlib/alloca.h b/stdlib/alloca.h
index 2d592d4..255af45 100644
--- a/stdlib/alloca.h
+++ b/stdlib/alloca.h
@@ -32,7 +32,7 @@  __BEGIN_DECLS
 extern void *alloca (size_t __size) __THROW;
 
 #ifdef __GNUC__
-# define alloca(size)  __builtin_alloca (size)
+# define alloca(size)  (VERIFY_ALLOCA (size) ? __builtin_alloca (size) : (abort, NULL))
 #endif /* GCC.  */
 
 __END_DECLS