Re: Commit: Use of alloca considered dangerous

[Jeff Law <law at redhat dot com>]

On 03/21/2016 11:12 AM, Paul_Koning@Dell.com wrote:
> > On Mar 21, 2016, at 12:58 PM, Jeff Law <law@redhat.com> wrote:
> >
> > On 03/21/2016 10:56 AM, Paul_Koning@Dell.com wrote:
> > > > On Mar 21, 2016, at 12:30 PM, Nick Clifton <nickc@redhat.com>
> > > > wrote:
> > > >
> > > > Hi Guys,
> > > >
> > > > 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
> 8th?
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 
vulnerable.

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.

Jeff