On August 10, 2016 8:00:20 PM GMT+02:00, Jeff Law <l...@redhat.com> wrote:
>On 08/10/2016 04:04 AM, Richard Biener wrote:
>> On Tue, Aug 9, 2016 at 3:17 PM, Aldy Hernandez <al...@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?
Yes, it's a set of tree code names.
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.
Yes, I understand that. The above is not such a case. If an attacker can
trick me into compiling (and possibly executing) his code then things are lost
anyway. No need for a fancy buffer overflow.
IMHO the alloca case warrants for a protection on the level of the stack
adjustment itself.
Richard.
>
>jeff
