On Mon, Feb 12, 2018 at 6:39 AM, Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> wrote: > 2018-02-12 2:56 GMT+09:00 Kees Cook <keescook@xxxxxxxxxxxx>: >> I think it would work to skip KBUILD_CPPFLAGS right up until it >> didn't. Since we have the arch split, we can already add -m32 to the >> 32-bit case, etc. However, I worry about interaction with other >> selected build options. For example, while retpoline doesn't interact >> stack-protector, it's easy to imagine things that might. I want to be sure I clarify: I'm not aware of any negative interaction between stack-protector and other options at present. I was just trying to think of an illustrative example. I do know we're about to get some per-architecture stack protector options (e.g. arm64 using a per-process canary instead of global), but I *think* that can be handled in the new Kconfig too. > One ugly solution could be > to add one more CC_HAS_ for the combination of the two ? Yeah, that seems reasonable, but it's a fix after the fact. I guess we'll have to see. >> (And in thinking about this, does Kconfig know the true $CC in use? >> i.e. the configured cross compiler, etc?) > > I was thinking of removing CONFIG_CROSS_COMPILE. > > A user can dynamically change CROSS_COMPILE from > "make menuconfig". Most builds I've seen implement cross compilers as an environment variable during all "make" invocations. > If we continue to support this, $CC changes > according to CONFIG_CROSS_COMPILE. > Then, compiler flags must be re-evaluated > every time a user changes a compiler in use. > It will introduce much more complexity. Right now, this is just handled in the Makefile: all the right variables exist, etc. -Kees -- Kees Cook Pixel Security -- 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
