> Improving the security of software has been a major trend in the recent > years. Fortunately, GCC offers a wide variety of flags that enable extra > hardening. These flags aren't enabled by default, though. And since > there are a lot of hardening flags, with more to come, it's been difficult > to keep on top of them; more so for the users of GCC who ought not to be > expected to keep track of all the new options. > > To alleviate some of the problems I mentioned, we thought it would > be useful to provide a new umbrella option that enables a reasonable set > of hardening flags. What's "reasonable" in this context is not easy to > pin down. Surely, there must be no ABI impact, the option cannot cause > severe performance issues, and, I suspect, it should not cause build > errors by enabling stricter compile-time errors (such as, -Wimplicit-int, > -Wint-conversion). Including a controversial option in -fhardened > would likely cause that users would not use -fhardened at all. It's > roughly akin to -Wall or -O2 -- those also enable a reasonable set of > options, and evolve over time, and are not kept in sync with other > compilers. > > Currently, -fhardened enables: > > -D_FORTIFY_SOURCE=3 (or =2 for older glibcs) > -D_GLIBCXX_ASSERTIONS > -ftrivial-auto-var-init=zero > -fPIE -pie -Wl,-z,relro,-z,now > -fstack-protector-strong > -fstack-clash-protection > -fcf-protection=full (x86 GNU/Linux only) > > -fsanitize=undefined is specifically not enabled. -fstrict-flex-arrays is > also liable to break a lot of code so I didn't include it. > > Appended is a proof-of-concept patch. It doesn't implement --help=hardened > yet. A fairly crucial point is that -fhardened will not override options > that were specified on the command line (before or after -fhardened). For > example, > > -D_FORTIFY_SOURCE=1 -fhardened > > means that _FORTIFY_SOURCE=1 will be used. Similarly, > > -fhardened -fstack-protector > > will not enable -fstack-protector-strong. > > Thoughts?
I think this is a great idea! Considering that it is difficult to decide what shoud be activated and what not and the baseline should not cause compile errors, I wonder whether there should be higher levels similar to -O1,2,3 ? Although it would be nice to have a one-letter or very short option similar to -O2 or -Wall, but maybe this is not possible because all short ones are already taken. Of course, "-fhardening" would already a huge improvement to the current situation. Martin
