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

Jeff Law law@redhat.com
Wed May 1 21:01:00 GMT 2013


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.


-  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.

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.

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


Jeff



More information about the Gcc-patches mailing list