On Wed, Aug 30, 2023 at 10:46:14AM +0200, Martin Uecker wrote: > > 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 ? Thanks. I would like to avoid any levels if at all possible; I think they would be confusing.
> 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. There are some free ones, like -Z, but I'm not confident I could take it :). Marek
