This is an archive of the discontinued LLVM Phabricator instance.

[stack protector] Add command line option -fstack-protector-strong.
ClosedPublic

Authored by jmagee on Feb 6 2014, 12:27 PM.

Details

Summary

Hi,

This patch adds the command line option "-fstack-protector-strong".

This option has the following affects:

  • It adds the ssp-strong IR attribute to each function within the CU.
  • It defines the macro SSP_STRONG with the value of 2.

Note that the patch changes the semantics of the frontend option
(-stack-protector) such that:

Before                                 After
-stack-protector 0 : Disable ssp.      -stack-protector 0 : Disable ssp
-stack-protector 1 : Generate ssp.     -stack-protector 1 : Generate ssp
-stack-protector 2 : Generate sspreq.  -stack-protector 2 : Generate sspstrong
                                       -stack-protector 3 : Generate sspreq.

Placing ssp-strong between ssp and sspreq (a.k.a, "all") is a logical choice (in terms of level of protection), although it does change the -cc1 interface. (Hopefully not an issue; I mention it just in case.)

Does this look good to go in?

Thanks,

  • Josh

Diff Detail

Event Timeline

jmagee updated this revision to Unknown Object (????).Feb 6 2014, 12:30 PM

Hi Josh,

The patch looks good to me. Thanks for the awesome functionality.

One minor suggestion: Is it possible to use LangOptions::SSP{On,Off,Req,Strong} instead of literal number? Like

if (A->getOption().matches(options::OPT_fstack_protector))
  StackProtectorLevel = LangOptions::SSPOn;

Thanks,
Weiming

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

jmagee updated this revision to Unknown Object (????).Feb 7 2014, 1:01 PM

I updated the patch to use values from LangOptions::StackProtectorMode instead of literals.

I needed to include Basic/LangOptions.h. It made me hesitate momentarily out of concern if this could possibly be a layering violation?
Furthermore, the same type of refactoring could be applied to the usage of GetDefaultStackProtectorLevel. (Which if I did, I would prefer to do as a separate patch.)

I agree with the idea of using the enumeration values instead of literals, but hesitate slightly because of the above concern. It is probably fine, but the separation of the frontend and driver is sometimes murky to me.

What do you think?

Thanks,

  • Josh

Hi Josh,

Thanks for the patch. LGTM.

When I made the suggestion, I had the same concern.
But I think we're doing the right thing: exposing the logic clearly by connecting the def and use.

Thanks,
Weiming

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

jmagee closed this revision.Feb 10 2014, 5:41 PM

Closed by commit rL201120 (authored by @jmagee).