On Mon, 2016-06-13 at 13:11 -0700, Kees Cook wrote: > On Mon, Jun 13, 2016 at 11:32 AM, Austin S. Hemmelgarn > <ahferroin7@xxxxxxxxx> wrote: > > On 2016-06-12 20:18, Emese Revfy wrote: > > > > > > On Sun, 12 Jun 2016 15:25:39 -0700 > > > Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > > > > > > I don't like this because it means if someone specifically selects > > > > some plugins in their .config, and the headers are missing, the kernel > > > > will successfully compile. For many plugins, this results in a kernel > > > > that lacks the requested security features, and that I really do not > > > > want to have happening. I'm okay leaving these disabled for compile > > > > tests for now. We can revisit this once more distros have plugins > > > > enabled by default. > > > > > > You are right. Your patch is safer. > > > > > Why not make it so that if COMPILE_TEST is enabled, the build warns if it > > can't find the headers, otherwise it fails? That way, people who are doing > > all*config builds but don't have the headers will still get some build > > coverage, and the people who are enabling it as a security feature will > > still get build failures. > > I don't see a clear way to do this, but if you can find a way to make > that happen, please send a patch! :) Another option is to make the top-level option negative, that way when it's enabled by allmod/yes the plugins are turned off. So eg. you would have: config DISABLE_GCC_PLUGINS bool "Disable building GCC plugins" default y ... This makes all the problems with allmod/yes go away, and means you always honor the users intent - when DISABLE_GCC_PLUGINS=n you can fail the build if you can't build the plugins. The downside is the logic's a bit awkward, ie. to enable the plugins you have to disable the option which disables them. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
