This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: why Glibc does use alloca?
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Jeff Law <law at redhat dot com>
- 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 18:09:03 +0200
- Subject: Re: why Glibc does use alloca?
- 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> <537630BB dot 7030701 at redhat dot com>
On Fri, May 16, 2014 at 09:37:31AM -0600, Jeff Law wrote:
> On 05/16/14 07:53, OndÅej BÃlka wrote:
> >>
> >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.
> Better yet, stop using alloca.
>
> Seriously. I don't have hard data, but there's little doubt in my
> mind that if we were to look at CVEs for glibc, the majority are due
> to unbound allocas.
>
> Experience clearly shows that we consistently get it wrong with
> alloca. IMHO, it should simply be banned from glibc (and
> everywhere, but let's start small).
>
> Yes, I know it's orders of magnitude faster than malloc. Yes I know
> we get automagic cleanup. But if using it consistently results in
> incorrect code that attackers can exploit, then the performance
> aspects really should take a back seat.
>
Problem is that security advice is useless when nobody follows it.
One could add a gcc configure option, say --alloca-as-malloc that turn
alloca into malloc with builtin to do cleanup, say
#define alloca(x) free_at_exit (malloc (x))
How many users would use it?
There is additional dull knife risk. If alloca is not available then
users that want performance will replace it with 64k arrays and malloc
fallback which makes overflow more likely.
It is matter of giving choice that is both safe and effective.