On August 10, 2016 8:00:20 PM GMT+02:00, Jeff Law <[email protected]> wrote: >On 08/10/2016 04:04 AM, Richard Biener wrote: >> On Tue, Aug 9, 2016 at 3:17 PM, Aldy Hernandez <[email protected]> >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
