Patch ping - Add a new option "-fstack-protector-strong"

[Han Shen(沈涵)]

On Wed, May 1, 2013 at 2:00 PM, Jeff Law <law@redhat.com> wrote:
> On 04/26/2013 10:45 AM, Han Shen(沈涵) wrote:
>>
>> Hi, I'd like to ping the patch '-fstack-protector-strong':
>>
>> - http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00945.html
>>    Add a new option '-fstack-protector-strong' to protect only
>> stack-smashing-vulnerable functions.
>>
>> Thanks,
>> H.
>>
>
> In cfgexpand.c, please make the constants an enum rather than #define. The
> former is visible in a debugger, the latter generally isn't.  If you could
> order them numerically, it'd be helpful as well.
Done.
>
>
> -  if (flag_stack_protect == 2)
> +  if (flag_stack_protect == SPCT_FLAG_ALL ||
> +      flag_stack_protect == SPCT_FLAG_STRONG)
>
> GNU coding standards mandate the operator go on the next line when splitting
> lines.  So something like
>
>   if (flag_stack_protect == SPCT_FLAG_ALL
>       || flag_stack_protect == SPCT_FLAG_STRONG)
>
>
> Similarly in expand_used_vars.

Thanks, done. (New patched replied in the original thread.)

>
> How do you plan on handling Florian's retslot issue?  Are you going to scan
> the gimple looking for suitable calls?  How do you avoid instrumentation in
> the callee for that case?
>
> I find myself wondering if you'd be better off scanning the gimple
> representation looking for ADDR_EXPR operations, then peeking at the
> argument to see if it's part of the local frame or something higher up.
>
> Prsumably you catch cases where the ABI mandates that certain arguments be
> copied by the caller and the address passed to the callee?  What about the
> opposite (and yes, both exist).  See TARGET_PASS_BY_REFERENCE,
> TARGET_CALLEE_COPIES.  I suspect scanning the gimple code is much more
> likely to pick up this stuff.

Yeah, I see. That's are good suggestions. I'll amend these (probably
minor) cases in another patch - if no objection to that -
which needs a good testing/performance/security measurement.

>
> Generally I like the idea of getting better stack smashing coverage without
> the penalty of stack-protector-all.
>
>
> Jeff

Han