> On Aug 29, 2023, at 3:42 PM, Marek Polacek via Gcc-patches > <gcc-patches@gcc.gnu.org> 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?
In general, I think that it is a very good idea to provide umbrella options for software security purpose. Thanks a lot for this work! 1. I do agree with Martin, multiple-level control for this purpose might be needed, similar as multiple levels for warnings, and multiple levels for optimizations. Similar as optimization options, can we organize all the security options together In our manual, then the user will have a good central place to get more and complete Information of the security features our compiler provides? 2. What’s the major criteria to decide which security feature should go into this list? Later, when we have new security features, how to decide whether to add them to This list or not? I am wondering why -fzero-call-used-regs is not included in the list and also Why chose -ftrivial-auto-var-init=zero instead of -ftrivial-auto-var-init=pattern? 3. Looks like currently, -fhardened excludes all compilation-time Warning options for security purpose, (For example, -Warray-bounds, --Wstringop-overflow…) And also excludes all sanitizer options for security purpose (-fsanitizer=undifined) So, shall we also provide an umbrella option for compilation-time warning options for security purpose And a umbrella option for sanitizer options (is the -fsanitizer=undefined this one)? Just some thoughts. -:). Qing
