On Fri, Sep 01, 2023 at 10:09:28PM +0000, Qing Zhao via Gcc-patches wrote: > > > > 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!
And thank you for taking a look! > 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. As I just mentioned in the other email, I'm reluctant to add more levels, like -fhardened=2, at this time. I think it's confusing, because if there are multiple choices, then as a user you have to figure out which one you want and this option is supposed to simplify things, not to puzzle people with one more decision. > 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? Maybe. But going through all the options and deciding whether it's a security options may be too big a task, especially if we are not exactly sure how we define security. > 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? >From my original post: 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. > 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? I can't readily evaluate the effect of -fzero-call-used-regs. But I did change =zero to =pattern. > 3. Looks like currently, -fhardened excludes all compilation-time Warning > options for security purpose, > (For example, -Warray-bounds, --Wstringop-overflow…) Correct. > And also excludes all sanitizer options for security purpose > (-fsanitizer=undifined) Correct. > So, shall we also provide an umbrella option for compilation-time warning > options for security purpose I don't think so... we already have -Wall and -Wextra. > And a umbrella option for sanitizer options (is the -fsanitizer=undefined > this one)? Yes, -fsanitizer=undefined is already an umbrella option. Thanks, Marek
