Messages in this thread | | | From | Kees Cook <> | Date | Mon, 12 Feb 2018 07:24:45 -0800 | Subject | Re: [RFC PATCH 4/7] kconfig: support new special property shell= |
| |
On Mon, Feb 12, 2018 at 6:39 AM, Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > 2018-02-12 2:56 GMT+09:00 Kees Cook <keescook@chromium.org>: >> 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
| |