On Tue, Feb 13, 2018 at 01:10:34AM +0900, Masahiro Yamada wrote: > 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. > Since the discussions in this thread are going in a million different directions and making my head hurt, ping me if I'm needed re. the WANT_* stuff or anything else. Masahiro's two-symbol version is much simpler and neater if the caveats re. "fallback" are minor enough to not matter. :) Cheers, Ulf -- 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