Re: protected alloca class for malloc fallback

[Jeff Law <law@redhat.com>]

On 08/10/2016 04:04 AM, Richard Biener wrote:
> On Tue, Aug 9, 2016 at 3:17 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
>> On 08/05/2016 01:55 PM, Richard Biener wrote:
>>
>> Hi Richard.
>>
>>> Please don't use std::string.  For string building you can use obstacks.
>>
>>
>> Alright let's talk details then so I can write things up in a way you
>> approve of.
>>
>> Take for instance simple uses like all the tree_*check_failed routines,
>> which I thought were great candidates for std::string-- they're going to be
>> outputted to the screen or disk which is clearly many times more expensive
>> than the malloc or overhead of std::string:
>>
>>       length += strlen ("expected ");
>>       buffer = tmp = (char *) alloca (length);
>>       length = 0;
>>       while ((code = (enum tree_code) va_arg (args, int)))
>>         {
>>           const char *prefix = length ? " or " : "expected ";
>>
>>           strcpy (tmp + length, prefix);
>>           length += strlen (prefix);
>>           strcpy (tmp + length, get_tree_code_name (code));
>>           length += strlen (get_tree_code_name (code));
>>         }
>>
>> Do you suggest using obstacks here, or did you have something else in mind?
>
> Why would you want to get rid of the alloca here?
Do you know the range for LENGTH in the code above?  Is it based on 
something the user could potentially control (like a variable name, 
typdef name, etc).  If you don't know the length or it's possibly under 
the control of the user, then this can blow out the stack, which makes 
the code vulnerable to a stack shifting style attack by which further 
writes into the stack are actually writing into other parts of the 
stack, the heap, plt or some other location.  Essentially this gives an 
attacker control over one or more stores to memory, which is often 
enough of a vulnerability to mount an attack.

jeff