2018-02-13 0:46 GMT+09:00 Kees Cook <keescook@xxxxxxxxxxxx>: > On Mon, Feb 12, 2018 at 2:44 AM, Masahiro Yamada > <yamada.masahiro@xxxxxxxxxxxxx> wrote: >> Linus said: >> >>> But yes, I also reacted to your earlier " It can't silently rewrite it >>> to _REGULAR because the compiler support for _STRONG regressed." >>> Because it damn well can. If the compiler doesn't support >>> -fstack-protector-strong, we can just fall back on -fstack-protector. >>> Silently. No extra crazy complex logic for that either. >> >> >> If I understood his comment correctly, >> we do not need either WANT_* or _AUTO. >> >> >> Kees' comment: >> >>> In the stack-protector case, this becomes quite important, since the >>> goal is to record the user's selection regardless of compiler >>> capability. For example, if someone selects _REGULAR, it shouldn't >>> "upgrade" to _STRONG. (Similarly for _NONE.) >> >> No. Kconfig will not do this silently. >> >> "make oldconfig" (or "make silentoldconfig" as well) >> always ask users about new symbols. > > The case I want to make sure can never happen is to have a config > setting that ends up not actually being true. For example, if > CONFIG_CC_STACKPROTECTOR appears in /proc/config.gz but the kernel > wasn't actually built with a stack protector, that's bad. We end up in > a place where the user can't trust the config to represent the actual > results of the build. > > So, as long as the Kconfig options are strongly tied to the compiler > capabilities, we're good on that front. > >> So, I can suggest to remove _REGULAR and _NONE. >> >> We have just two bool options, like follows. >> >> ------------------->8----------------- >> config CC_STACKPROTECTOR >> bool "Use stack protector" >> depends on CC_HAS_STACKPROTECTOR >> >> config CC_STACKPROTECTOR_STRONG >> bool "Use strong strong stack protector" >> depends on CC_STACKPROTECTOR >> depends on CC_HAS_STACKPROTECTOR_STRONG >> -------------------->8------------------ >> >> This will work well for all{yes,mod,no}config. > > This two-option arrangement is fine (though it assumes there won't be > another stack protector option in the future). > > The issue I have is this removes _AUTO, which I think can be solved in > the two-option arrangement too. The purpose of _AUTO is to effectively > enable stack-protector by default. As this option has been available > for over 10 years, and all distros enable it, it's an obvious > candidate to be enabled-by-default, especially since it kills a class > of exploits (as mentioned in my commit log: BlueBorne was trivially > defeated with stack-protector). So it should be possible to make these > two options "default y", yes? Yes. Both should be "default y" to keep the equivalent behavior since the current default is _AUTO. >> We will not have a case where >> -fstack-protector-strong is supported, but -fstack-protector is not. > > Correct. > > -Kees > > -- > Kees Cook > Pixel Security > -- > To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html