This is the mail archive of the
mailing list for the glibc project.
Re: why Glibc does not build with clang?
- From: Rich Felker <dalias at libc dot org>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Florian Weimer <fweimer at redhat dot com>, Will Newton <will dot newton at linaro dot org>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 16 May 2014 17:32:00 -0400
- Subject: Re: why Glibc does not build with clang?
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdw135gBO+cTQx3Ws1GrRgFsi8-j=Y_mZ=ixebpPzB4gXw at mail dot gmail dot com> <53760025 dot 10204 at redhat dot com> <CANu=DmhF=PZBVHtOPw5ZMCHjcy6vqdCvrRvY+xO9hzfkjTCRQA at mail dot gmail dot com> <53760826 dot 6090203 at redhat dot com> <20140516135304 dot GA29829 at domone dot podge> <20140516190504 dot GF507 at brightrain dot aerifal dot cx> <20140516203140 dot GA16889 at domone dot podge>
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?
> 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.
> > 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.