Commit: Use of alloca considered dangerous

[Jeff Law]

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