#1128 switching from "-fstack-protector" to "-fstack-protector-strong" in Fedora 20

Created 4 years ago by halfie
Modified 4 years ago

= Proposal =

The new compiler flag "-fstack-protector-strong" in Fedora 19's gcc achieves a
better balance between security and performance (when compared against the
default -fstack-protector and available -fstack-protector-all options).

I am proposing to switch from using the "-fstack-protector" flag to
"-fstack-protector-strong" in Fedora 20. The switch involves changing a single
line in /usr/lib/rpm/redhat/macros file.

  1. In preliminary benchmarking, using "-fstack-protector-strong" did not result
    in any performance regressions.

  2. Benefit over "-fstack-protector-all" => gains big performance while
    sacrificing little security.

  3. Benefit over the current default "-fstack-protector" => "-fstack-protector" is
    regarded as "not secure enough" (only "protects" < 2% functions in Chromium
    project). "-fstack-protector-strong" hits the balance between the
    over-simplified "-fstack-protector" and over-killing
    "-fstack-protector-all".

  4. Google Chromium project has been using this compiler option for over an year
    now with "no securiy degradation".

  5. FWIW, "-fstack-protector-strong" evaluation and possible inclusion is on Ubuntu's road-map as well.

(I have paraphrased and summarized multiple posting by Han Shen, the developer
of "-fstack-protector-strong" patch).

= Details =

  1. The design and implementation of "-fstack-protector-strong" can be found at,

https://docs.google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU/

The stack-protector option is over-simplified, which ignores pointer cast,
address computation, while the stack-protector-all is over-killing, using
this option results in too much performance overhead.

"-fstack-protector-strong" tries to hit the balance between an
over-simplified version and an over-killing protection schema.

  1. "-fstack-protector-strong" chooses more functions to be protected than
    "stack-protector", it is a superset of "stack-protector", for functions not
    chosen by "stack-protector". "stack-protector-strong" will apply protection
    if any of the following conditions meets.
  • if any of its local variable’s address is taken,as part of the RHS of an
    assignment
  • or if any of its local variable’s address is taken as part of a function
    argument.
  • or if it has an array, regardless of array type or length
  • or if it has a struct/union which contains an array, regardless of array
    type or length.
  • or if function has register local variables

'''I am currently working on running more benchmarks.'''

Setting "meeting" keyword.

This certainly seems beneficial to the system, provided of course that additional performance testing doesn't show a significant degradation.

CCing Jakub for his input.

Replying to [ticket:1128 halfie]:

  1. Benefit over the current default "-fstack-protector" => "-fstack-protector" is
    regarded as "not secure enough" (only "protects" < 2% functions in Chromium
    project).

I don't have a strong opinion on the proposal in general; however, this specific claim is being inherited from one proposal to another and shouldn't stand: "percentage of of functions affected by the compiler option" is useless as a measure.

"Percentage of vulnerabilities mitigated" or "percentage of attacks prevented" would be the relevant measures - much more difficult to estimate, sure, but that doesn't make the "percentage of affected functions" useful, even in comparison.

Also, it seems to me rather suspect that the option can have ''both'' much higher coverage and no performance impact. The option is adding extra instructions to every affected function, so how is that possible?

Replying to [comment:2 mitr]:

Replying to [ticket:1128 halfie]:

  1. Benefit over the current default "-fstack-protector" => "-fstack-protector" is
    regarded as "not secure enough" (only "protects" < 2% functions in Chromium
    project).

I don't have a strong opinion on the proposal in general; however, this specific claim is being inherited from one proposal to another and shouldn't stand: "percentage of of functions affected by the compiler option" is useless as a measure.

Agreed.

I should have mentioned that Google was using "-fstack-protector-all" (probably due to "-fstack-protector" being found "inadequate") earlier. They switched to using "-fstack-protector-strong" around January 2012.

"Percentage of vulnerabilities mitigated" or "percentage of attacks prevented" would be the relevant measures - much more difficult to estimate, sure, but that doesn't make the "percentage of affected functions" useful, even in comparison.

Measuring or even estimating "Percentage of vulnerabilities mitigated" is a very HARD problem to solve on a large scale I think.

My "ssp-coverage" utility (https://bitbucket.org/dhiru/ssp-coverage/src) can help in determining how many function stacks are being protected by stack canaries.

Also, it seems to me rather suspect that the option can have ''both'' much higher coverage and no performance impact. The option is adding extra instructions to every affected function, so how is that possible?

I agree with your reasoning.

Maybe after reading http://www-plan.cs.colorado.edu/diwan/asplos09.pdf, I will get some answers.

Jakub - any comments?

I have no problem with enabling -fstack-protector-strong for hardened packages, and for others as long as benchmarks show it doesn't introduce significant overhead.
I'll just note that -fstack-protector-strong option is significantly less tested than -fstack-protector, which is included even in gcc %check build time testing; if -fstack-protector-strong is switched on by default, I could switch %check to test -fstack-protector-strong instead though.

From 2013-06-26 FESCo meeting:

AGREED: Will switch from "-fstack-protector" to "-fstack-protector-strong" in Fedora 20. Any reversion based on poor benchmarks must be decided before any F20 gcc mass rebuild (+:6, -:0, 0:0)

Halfie - please file a bug/patch for redhat-rpm-config?

Replying to [comment:6 notting]:

From 2013-06-26 FESCo meeting:
Halfie - please file a bug/patch for redhat-rpm-config?

Done. https://bugzilla.redhat.com/show_bug.cgi?id=978763

Patch uploaded too.

At the FESCo meeting on 2013-07-03, this ticket was declared complete. We will follow up on Bugzilla to ensure that the patch lands in time for the F20 mass-rebuild.

Login to comment on this ticket.