Hello all,
On 09/27/18 02:05, Christophe Leroy wrote:
[..snip..]
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 07d9dce7eda6..45b8eb4d8fe7 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -112,6 +112,9 @@ KBUILD_LDFLAGS += -m elf$(BITS)$(LDEMULATION)
> KBUILD_ARFLAGS += --target=elf$(BITS)-$(GNUTARGET)
> endif
>
> +cflags-$(CONFIG_STACKPROTECTOR) += -mstack-protector-guard=tls
> +cflags-$(CONFIG_STACKPROTECTOR) += -mstack-protector-guard-reg=r2
> +
> LDFLAGS_vmlinux-y := -Bstatic
> LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) := -pie
> LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-y)
> @@ -404,6 +407,13 @@ archclean:
>
> archprepare: checkbin
>
> +ifdef CONFIG_STACKPROTECTOR
> +prepare: stack_protector_prepare
> +
> +stack_protector_prepare: prepare0
> + $(eval KBUILD_CFLAGS += -mstack-protector-guard-offset=$(shell awk '{if
> ($$2 == "TASK_CANARY") print $$3;}' include/generated/asm-offsets.h))
> +endif
> +
This breaks when building out-of-tree kernel modules. GCC is not getting passed
the -mstack-protector-guard-offset argument, so the default offset is used. The
kernel then panics the first time a function with stack protector is called.
I'm seeing this on powerpc64. It looks like it was reported for powerpc on
kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201891
Linux 4.20 does not have a "prepare" target when KBUILD_EXTMOD is set. One is
added by:
commit e07db28eea38ed4e332b3a89f3995c86b713cb5b
Author: Masahiro Yamada <yamada.masah...@socionext.com>
Date: Thu Nov 22 08:11:54 2018 +0900
kbuild: fix single target build for external module
However, after cherry-picking that patch, the build fails because it's missing
prepare0. I applied the patch below and I successfully built an out-of-tree
module with CONFIG_STACKPROTECTOR=y.
diff --git a/Makefile b/Makefile
index 826826553085..f0a93e1ba1b6 100644
--- a/Makefile
+++ b/Makefile
@@ -1596,9 +1596,10 @@ help:
@echo ''
# Dummies...
-PHONY += prepare scripts
-prepare:
+PHONY += prepare prepare0 scripts
+prepare: prepare0
$(cmd_crmodverdir)
+prepare0: ;
scripts: ;
endif # KBUILD_EXTMOD
The context has been changed some in later patches, but I think a change like
this one should go into 5.0, and it e07db28eea38 should go into 4.20.y.
Thanks,
Samuel
