= 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.
In preliminary benchmarking, using "-fstack-protector-strong" did not result in any performance regressions.
Benefit over "-fstack-protector-all" => gains big performance while sacrificing little security.
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".
Google Chromium project has been using this compiler option for over an year now with "no securiy degradation".
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 =
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.
'''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]:
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]: 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.
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.
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.
Log in to comment on this ticket.