This is the mail archive of the
mailing list for the binutils project.
Re: Commit: Use of alloca considered dangerous
- From: Jeff Law <law at redhat dot com>
- To: Paul_Koning at Dell dot com
- Cc: nickc at redhat dot com, binutils at sourceware dot org
- Date: Mon, 21 Mar 2016 11:15:08 -0600
- Subject: Re: Commit: Use of alloca considered dangerous
- Authentication-results: sourceware.org; auth=none
- References: <87mvprx079 dot fsf at redhat dot com> <B1F8A0EC-9D4D-459E-899A-5638E2CCE924 at dell dot com> <56F0284B dot 3010004 at redhat dot com> <5CFD6B41-561A-4058-85FE-3333931BC0F1 at dell dot com>
On 03/21/2016 11:12 AM, Paul_Koning@Dell.com wrote:
Only if the 8th is highly unlikely to change, including its context.
For example, if the 8th gets shoved inside a loop, then it becomes
On Mar 21, 2016, at 12:58 PM, Jeff Law <firstname.lastname@example.org> wrote:
On 03/21/2016 10:56 AM, Paul_Koning@Dell.com wrote:
On Mar 21, 2016, at 12:30 PM, Nick Clifton <email@example.com>
It was pointed out to me the other day that there are some
unbounded calls to alloca in the binutils, which in theory
could lead to exploits. So I tried adding -Wstack-usage=NNN to
the command line and discovered that gcc would complain about
any use of alloca, even bounded ones. Still they were easy to
fix, and removing the use of alloca, and variable length local
arrays as well, seems like a good idea.
I agree that alloca() needs bounds checks, but I don't see why
you say that avoiding alloca entirely is "a good idea".
Based on what I've seen through the years, if you can't put a hard
bounds on an alloca, then you're far better off from a security
standpoint avoiding it completely.
Absolutely. But isn't that a case by case test? If 7 uses of alloca
don't have a guaranteed hard bound but the 8th one does, then I agree
the 7 have to change -- but would it not be reasonable to keep the
I think the right model is to have the compiler determine safety and
optimize a malloc/free pair to alloca when it can be proven safe.