Qing Zhao via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >> 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
FWIW, I wondered the same thing. Not a strong conviction that it should be included -- maybe the code bloat is too much on some targets. But it might be acceptable for the -fhardened equivalent of -O3, at least if restricted to GPRs. > Why chose -ftrivial-auto-var-init=zero instead of > -ftrivial-auto-var-init=pattern? Yeah, IIRC -ftrivial-auto-var-init=zero was controversial with some Clang maintainers because it effectively creates a language dialect. -ftrivial-auto-var-init=pattern wasn't controversial in the same way. Thanks, Richard
