Message ID | 20210304113708.215121-1-masahiroy@kernel.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | kbuild: rebuild GCC plugins when the compiler is upgraded | expand |
On Thu, Mar 04, 2021 at 08:37:08PM +0900, Masahiro Yamada wrote: > Linus reported a build error due to the GCC plugin incompatibility > when the compiler is upgraded. [1] > > cc1: error: incompatible gcc/plugin versions > cc1: error: failed to initialize plugin ./scripts/gcc-plugins/stackleak_plugin.so > > GCC plugins are tied to a particular GCC version. So, they must be > rebuilt when the compiler is upgraded. > > This seems to be a long-standing flaw since the initial support of > GCC plugins. > > Extend commit 8b59cd81dc5e ("kbuild: ensure full rebuild when the > compiler is updated"), so that GCC plugins are covered by the > compiler upgrade detection. > > [1]: https://lore.kernel.org/lkml/CAHk-=wieoN5ttOy7SnsGwZv+Fni3R6m-Ut=oxih6bbZ28G+4dw@mail.gmail.com/ > > Reported-by: Linus Torvalds <torvalds@linux-foundation.org> > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> This seems fine to me, but I want to make sure Josh has somewhere to actually go with this. Josh, does this get you any closer? It sounds like the plugins need to move to another location for packaged kernels? Reviewed-by: Kees Cook <keescook@chromium.org>
On Thu, Mar 4, 2021 at 3:20 PM Kees Cook <keescook@chromium.org> wrote: > > This seems fine to me, but I want to make sure Josh has somewhere to > actually go with this. Josh, does this get you any closer? It sounds > like the plugins need to move to another location for packaged kernels? Well, it might be worth extending the stuff that gets installed with /lib/modules/<kernel-version>/ with enough information and infrastruvcture to then build any external modules. Yeah, yeah, there's the /boot/config-<kernelversion> thing too, but honestly, that probably shouldn't have been in /boot to begin with. That, and the plugins - and possibly any hashes needed for randstruct etc - might be good to squirrell away in a /lib/modules/<kernelversion>/build/ subdirectory? I dunno. I obviously don't build external modules to begin with, much less with distro kernels... Linus
On Thu, Mar 04, 2021 at 03:37:14PM -0800, Linus Torvalds wrote: > On Thu, Mar 4, 2021 at 3:20 PM Kees Cook <keescook@chromium.org> wrote: > > > > This seems fine to me, but I want to make sure Josh has somewhere to > > actually go with this. Josh, does this get you any closer? No, this doesn't seem to help me at all. > > It sounds like the plugins need to move to another location for > > packaged kernels? > > Well, it might be worth extending the stuff that gets installed with > /lib/modules/<kernel-version>/ with enough information and > infrastruvcture to then build any external modules. The gcc plugins live in scripts/, which get installed by "make modules_install" already. So the plugins' source and makefiles are in /lib/modules/<kernel-version>/build/scripts/gcc-plugins. So everything needed for building the plugins is already there. We just need the kernel makefiles to rebuild the plugins locally, when building an external module.
On Thu, Mar 04, 2021 at 08:25:00PM -0600, Josh Poimboeuf wrote: > On Thu, Mar 04, 2021 at 03:37:14PM -0800, Linus Torvalds wrote: > > On Thu, Mar 4, 2021 at 3:20 PM Kees Cook <keescook@chromium.org> wrote: > > > > > > This seems fine to me, but I want to make sure Josh has somewhere to > > > actually go with this. Josh, does this get you any closer? > > No, this doesn't seem to help me at all. > > > > It sounds like the plugins need to move to another location for > > > packaged kernels? > > > > Well, it might be worth extending the stuff that gets installed with > > /lib/modules/<kernel-version>/ with enough information and > > infrastruvcture to then build any external modules. > > The gcc plugins live in scripts/, which get installed by "make > modules_install" already. So the plugins' source and makefiles are in > /lib/modules/<kernel-version>/build/scripts/gcc-plugins. > > So everything needed for building the plugins is already there. We just > need the kernel makefiles to rebuild the plugins locally, when building > an external module. This seems to work with very limited testing... Based on top of Masahiro's recent patch: https://lkml.kernel.org/r/CAK7LNARHoTnZ3gAvHgnYB4n-wYuboxC10A6zURh1ODGhxWd2yA@mail.gmail.com From: Josh Poimboeuf <jpoimboe@redhat.com> Subject: [PATCH] gcc-plugins: Rebuild plugins in external module directory When building external kernel modules, the build system doesn't require the GCC version to match the version used to build the original kernel. In fact, most distros release the compiler and the kernel in separate packages, with separate release cadences. So it's not uncommon for mismatches to occur. But with GCC plugins enabled, that's no longer allowed: cc1: error: incompatible gcc/plugin versions cc1: error: failed to initialize plugin ./scripts/gcc-plugins/structleak_plugin.so That error comes from the plugin's call to plugin_default_version_check(), which strictly enforces the GCC version. The strict check makes sense, because there's nothing to prevent the GCC plugin ABI from changing, and it often does. Since plugins are tightly tied to the compiler version, just rebuild them locally in the external module directory, and then use the local version in the external module build. Reported-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> --- Makefile | 1 + scripts/Makefile.gcc-plugins | 2 +- scripts/gcc-plugins/Makefile | 8 ++++++-- 3 files changed, 8 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index bc208886fcce..90c6656de224 100644 --- a/Makefile +++ b/Makefile @@ -1784,6 +1784,7 @@ prepare: echo " The kernel was built by: "$(CONFIG_CC_VERSION_TEXT); \ echo " You are using: $(CC_VERSION_TEXT)"; \ fi + $(Q)$(MAKE) $(build)=scripts/gcc-plugins PHONY += help help: diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins index 952e46876329..be4303678942 100644 --- a/scripts/Makefile.gcc-plugins +++ b/scripts/Makefile.gcc-plugins @@ -48,7 +48,7 @@ export DISABLE_ARM_SSP_PER_TASK_PLUGIN # All the plugin CFLAGS are collected here in case a build target needs to # filter them out of the KBUILD_CFLAGS. -GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y)) +GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD),$(objtree))/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y)) # The sancov_plugin.so is included via CFLAGS_KCOV, so it is removed here. GCC_PLUGINS_CFLAGS := $(filter-out %/sancov_plugin.so, $(GCC_PLUGINS_CFLAGS)) export GCC_PLUGINS_CFLAGS diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile index b5487cce69e8..9f8e2ef3ab56 100644 --- a/scripts/gcc-plugins/Makefile +++ b/scripts/gcc-plugins/Makefile @@ -1,10 +1,14 @@ # SPDX-License-Identifier: GPL-2.0 -$(obj)/randomize_layout_plugin.so: $(objtree)/$(obj)/randomize_layout_seed.h +ifneq ($(KBUILD_EXTMOD),) +override obj := $(KBUILD_EXTMOD)/$(obj) +endif + +$(obj)/randomize_layout_plugin.so: $(objtree)/$(src)/randomize_layout_seed.h quiet_cmd_create_randomize_layout_seed = GENSEED $@ cmd_create_randomize_layout_seed = \ $(CONFIG_SHELL) $(srctree)/$(src)/gen-random-seed.sh $@ $(objtree)/include/generated/randomize_layout_hash.h -$(objtree)/$(obj)/randomize_layout_seed.h: FORCE +$(objtree)/$(src)/randomize_layout_seed.h: FORCE $(call if_changed,create_randomize_layout_seed) targets += randomize_layout_seed.h randomize_layout_hash.h
On Sat, Mar 6, 2021 at 10:28 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Thu, Mar 04, 2021 at 08:25:00PM -0600, Josh Poimboeuf wrote: > > On Thu, Mar 04, 2021 at 03:37:14PM -0800, Linus Torvalds wrote: > > > On Thu, Mar 4, 2021 at 3:20 PM Kees Cook <keescook@chromium.org> wrote: > > > > > > > > This seems fine to me, but I want to make sure Josh has somewhere to > > > > actually go with this. Josh, does this get you any closer? > > > > No, this doesn't seem to help me at all. > > > > > > It sounds like the plugins need to move to another location for > > > > packaged kernels? > > > > > > Well, it might be worth extending the stuff that gets installed with > > > /lib/modules/<kernel-version>/ with enough information and > > > infrastruvcture to then build any external modules. > > > > The gcc plugins live in scripts/, which get installed by "make > > modules_install" already. So the plugins' source and makefiles are in > > /lib/modules/<kernel-version>/build/scripts/gcc-plugins. > > > > So everything needed for building the plugins is already there. We just > > need the kernel makefiles to rebuild the plugins locally, when building > > an external module. > > This seems to work with very limited testing... Based on top of > Masahiro's recent patch: > > https://lkml.kernel.org/r/CAK7LNARHoTnZ3gAvHgnYB4n-wYuboxC10A6zURh1ODGhxWd2yA@mail.gmail.com Is this a bad coding contest? I am not asking you to add ugly ifeq or whatever hacks to say "this worked for me". Please feel free to do this in the fedora kernel, but do not send it to upstream. Sorry, I really do not want to see hacks like this any more. Remember, how badly objtool was integrated in the build system, and you even blocked me from fixing that. > From: Josh Poimboeuf <jpoimboe@redhat.com> > Subject: [PATCH] gcc-plugins: Rebuild plugins in external module directory > > When building external kernel modules, the build system doesn't require > the GCC version to match the version used to build the original kernel. > > In fact, most distros release the compiler and the kernel in separate > packages, with separate release cadences. So it's not uncommon for > mismatches to occur. > > But with GCC plugins enabled, that's no longer allowed: > > cc1: error: incompatible gcc/plugin versions > cc1: error: failed to initialize plugin ./scripts/gcc-plugins/structleak_plugin.so > > That error comes from the plugin's call to > plugin_default_version_check(), which strictly enforces the GCC version. > The strict check makes sense, because there's nothing to prevent the GCC > plugin ABI from changing, and it often does. > > Since plugins are tightly tied to the compiler version, just rebuild > them locally in the external module directory, and then use the local > version in the external module build. > > Reported-by: Ondrej Mosnacek <omosnace@redhat.com> > Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> > --- > Makefile | 1 + > scripts/Makefile.gcc-plugins | 2 +- > scripts/gcc-plugins/Makefile | 8 ++++++-- > 3 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/Makefile b/Makefile > index bc208886fcce..90c6656de224 100644 > --- a/Makefile > +++ b/Makefile > @@ -1784,6 +1784,7 @@ prepare: > echo " The kernel was built by: "$(CONFIG_CC_VERSION_TEXT); \ > echo " You are using: $(CC_VERSION_TEXT)"; \ > fi > + $(Q)$(MAKE) $(build)=scripts/gcc-plugins > > PHONY += help > help: > diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins > index 952e46876329..be4303678942 100644 > --- a/scripts/Makefile.gcc-plugins > +++ b/scripts/Makefile.gcc-plugins > @@ -48,7 +48,7 @@ export DISABLE_ARM_SSP_PER_TASK_PLUGIN > > # All the plugin CFLAGS are collected here in case a build target needs to > # filter them out of the KBUILD_CFLAGS. > -GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y)) > +GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD),$(objtree))/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y)) > # The sancov_plugin.so is included via CFLAGS_KCOV, so it is removed here. > GCC_PLUGINS_CFLAGS := $(filter-out %/sancov_plugin.so, $(GCC_PLUGINS_CFLAGS)) > export GCC_PLUGINS_CFLAGS > diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile > index b5487cce69e8..9f8e2ef3ab56 100644 > --- a/scripts/gcc-plugins/Makefile > +++ b/scripts/gcc-plugins/Makefile > @@ -1,10 +1,14 @@ > # SPDX-License-Identifier: GPL-2.0 > > -$(obj)/randomize_layout_plugin.so: $(objtree)/$(obj)/randomize_layout_seed.h > +ifneq ($(KBUILD_EXTMOD),) > +override obj := $(KBUILD_EXTMOD)/$(obj) > +endif > + > +$(obj)/randomize_layout_plugin.so: $(objtree)/$(src)/randomize_layout_seed.h > quiet_cmd_create_randomize_layout_seed = GENSEED $@ > cmd_create_randomize_layout_seed = \ > $(CONFIG_SHELL) $(srctree)/$(src)/gen-random-seed.sh $@ $(objtree)/include/generated/randomize_layout_hash.h > -$(objtree)/$(obj)/randomize_layout_seed.h: FORCE > +$(objtree)/$(src)/randomize_layout_seed.h: FORCE > $(call if_changed,create_randomize_layout_seed) > targets += randomize_layout_seed.h randomize_layout_hash.h > > -- > 2.29.2 >
On Sat, Mar 06, 2021 at 11:18:31AM +0900, Masahiro Yamada wrote: > On Sat, Mar 6, 2021 at 10:28 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > On Thu, Mar 04, 2021 at 08:25:00PM -0600, Josh Poimboeuf wrote: > > > On Thu, Mar 04, 2021 at 03:37:14PM -0800, Linus Torvalds wrote: > > > > On Thu, Mar 4, 2021 at 3:20 PM Kees Cook <keescook@chromium.org> wrote: > > > > > > > > > > This seems fine to me, but I want to make sure Josh has somewhere to > > > > > actually go with this. Josh, does this get you any closer? > > > > > > No, this doesn't seem to help me at all. > > > > > > > > It sounds like the plugins need to move to another location for > > > > > packaged kernels? > > > > > > > > Well, it might be worth extending the stuff that gets installed with > > > > /lib/modules/<kernel-version>/ with enough information and > > > > infrastruvcture to then build any external modules. > > > > > > The gcc plugins live in scripts/, which get installed by "make > > > modules_install" already. So the plugins' source and makefiles are in > > > /lib/modules/<kernel-version>/build/scripts/gcc-plugins. > > > > > > So everything needed for building the plugins is already there. We just > > > need the kernel makefiles to rebuild the plugins locally, when building > > > an external module. > > > > This seems to work with very limited testing... Based on top of > > Masahiro's recent patch: > > > > https://lkml.kernel.org/r/CAK7LNARHoTnZ3gAvHgnYB4n-wYuboxC10A6zURh1ODGhxWd2yA@mail.gmail.com > > Is this a bad coding contest? > > I am not asking you to add ugly ifeq or whatever > hacks to say "this worked for me". > > Please feel free to do this in the fedora kernel, > but do not send it to upstream. > > Sorry, I really do not want to see hacks like this any more. Geez, that's a bit harsh. I never claimed to be a brilliant makefile coder. Do you have any constructive feedback for improving the patch? > Remember, how badly objtool was integrated in the build system, > and you even blocked me from fixing that. I have no idea what you're talking about, nor how it would be relevant to this patch.
On Fri, Mar 05, 2021 at 08:50:59PM -0600, Josh Poimboeuf wrote: > > Is this a bad coding contest? > > > > I am not asking you to add ugly ifeq or whatever > > hacks to say "this worked for me". > > > > Please feel free to do this in the fedora kernel, > > but do not send it to upstream. > > > > Sorry, I really do not want to see hacks like this any more. Masahiro, Ping. Do you have a better approach for building GCC plugins in the external module directory?
On Wed, Mar 10, 2021 at 5:31 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Fri, Mar 05, 2021 at 08:50:59PM -0600, Josh Poimboeuf wrote: > > > Is this a bad coding contest? > > > > > > I am not asking you to add ugly ifeq or whatever > > > hacks to say "this worked for me". > > > > > > Please feel free to do this in the fedora kernel, > > > but do not send it to upstream. > > > > > > Sorry, I really do not want to see hacks like this any more. > > Masahiro, > > Ping. Do you have a better approach for building GCC plugins in the > external module directory? I am not sure if building GCC plugins in the external module directory is the right approach. -- Best Regards Masahiro Yamada
On Wed, Mar 10, 2021 at 10:44:46PM +0900, Masahiro Yamada wrote: > > Masahiro, > > > > Ping. Do you have a better approach for building GCC plugins in the > > external module directory? > > > I am not sure if building GCC plugins in the external module directory > is the right approach. I'm certainly open to any better ideas that would allow GCC plugins to be enabled in distro kernel builds.
diff --git a/Makefile b/Makefile index 44ab0dfd3698..5f66cf5af5f7 100644 --- a/Makefile +++ b/Makefile @@ -490,6 +490,7 @@ USERINCLUDE := \ -I$(objtree)/arch/$(SRCARCH)/include/generated/uapi \ -I$(srctree)/include/uapi \ -I$(objtree)/include/generated/uapi \ + -include $(srctree)/include/linux/compiler-version.h \ -include $(srctree)/include/linux/kconfig.h # Use LINUXINCLUDE when you must reference the include/ directory. diff --git a/include/linux/compiler-version.h b/include/linux/compiler-version.h new file mode 100644 index 000000000000..2b2972c77c62 --- /dev/null +++ b/include/linux/compiler-version.h @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifdef __LINUX_COMPILER_VERSION_H +#error "Please do not include <linux/compiler-version.h>. This is done by the build system." +#endif +#define __LINUX_COMPILER_VERSION_H + +/* + * This header exists to force full rebuild when the compiler is upgraded. + * + * When fixdep scans this, it will find this string "CONFIG_CC_VERSION_TEXT" + * and add dependency on include/config/cc/version/text.h, which is touched + * by Kconfig when the version string from the compiler changes. + */ diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h index e78e17a76dc9..24a59cb06963 100644 --- a/include/linux/kconfig.h +++ b/include/linux/kconfig.h @@ -2,8 +2,6 @@ #ifndef __LINUX_KCONFIG_H #define __LINUX_KCONFIG_H -/* CONFIG_CC_VERSION_TEXT (Do not delete this comment. See help in Kconfig) */ - #include <generated/autoconf.h> #ifdef CONFIG_CPU_BIG_ENDIAN diff --git a/init/Kconfig b/init/Kconfig index 0dd44d951e67..b6f641567b7c 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -20,10 +20,10 @@ config CC_VERSION_TEXT When the compiler is updated, Kconfig will be invoked. - Ensure full rebuild when the compiler is updated - include/linux/kconfig.h contains this option in the comment line so - fixdep adds include/config/cc/version/text.h into the auto-generated - dependency. When the compiler is updated, syncconfig will touch it - and then every file will be rebuilt. + include/linux/compiler-version.h contains this option in the comment + line so fixdep adds include/config/cc/version/text.h into the + auto-generated dependency. When the compiler is updated, syncconfig + will touch it and then every file will be rebuilt. config CC_IS_GCC def_bool $(success,test "$(cc-name)" = GCC) diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile index b5487cce69e8..1952d3bb80c6 100644 --- a/scripts/gcc-plugins/Makefile +++ b/scripts/gcc-plugins/Makefile @@ -22,6 +22,7 @@ always-y += $(GCC_PLUGIN) GCC_PLUGINS_DIR = $(shell $(CC) -print-file-name=plugin) plugin_cxxflags = -Wp,-MMD,$(depfile) $(KBUILD_HOSTCXXFLAGS) -fPIC \ + -include $(srctree)/include/linux/compiler-version.h \ -I $(GCC_PLUGINS_DIR)/include -I $(obj) -std=gnu++11 \ -fno-rtti -fno-exceptions -fasynchronous-unwind-tables \ -ggdb -Wno-narrowing -Wno-unused-variable \
Linus reported a build error due to the GCC plugin incompatibility when the compiler is upgraded. [1] cc1: error: incompatible gcc/plugin versions cc1: error: failed to initialize plugin ./scripts/gcc-plugins/stackleak_plugin.so GCC plugins are tied to a particular GCC version. So, they must be rebuilt when the compiler is upgraded. This seems to be a long-standing flaw since the initial support of GCC plugins. Extend commit 8b59cd81dc5e ("kbuild: ensure full rebuild when the compiler is updated"), so that GCC plugins are covered by the compiler upgrade detection. [1]: https://lore.kernel.org/lkml/CAHk-=wieoN5ttOy7SnsGwZv+Fni3R6m-Ut=oxih6bbZ28G+4dw@mail.gmail.com/ Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> --- Makefile | 1 + include/linux/compiler-version.h | 14 ++++++++++++++ include/linux/kconfig.h | 2 -- init/Kconfig | 8 ++++---- scripts/gcc-plugins/Makefile | 1 + 5 files changed, 20 insertions(+), 6 deletions(-) create mode 100644 include/linux/compiler-version.h