On Mon, Sep 04, 2023 at 11:40:34PM +0100, Richard Sandiford wrote: > 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.
I have no opinion here. I trust you so if you think it'd make sense, I will add it. :) The patch I posted today: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630550.html doesn't include that option yet. > > 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. I've adjusted the patch to enable -ftrivial-auto-var-init=pattern rather than -ftrivial-auto-var-init=zero. Marek
