On Tue, Jul 23, 2019 at 2:24 PM Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote: > > KBUILD_CFLAGS is very carefully built up in the top level Makefile, > particularly when cross compiling or using different build tools. > Resetting KBUILD_CFLAGS via := assignment is an antipattern. > > The comment above the reset mentions that -pg is problematic. Other > Makefiles use `CFLAGS_REMOVE_file.o = $(CC_FLAGS_FTRACE)` when > CONFIG_FUNCTION_TRACER is set. Prefer that pattern to wiping out all of > the important KBUILD_CFLAGS then manually having to re-add them. Seems > also that __stack_chk_fail references are generated when using > CONFIG_STACKPROTECTOR or CONFIG_STACKPROTECTOR_STRONG. > > Cc: stable@xxxxxxxxxxxxxxx > Fixes: 8fc5b4d4121c ("purgatory: core purgatory functionality") > Reported-by: Vaibhav Rustagi <vaibhavrustagi@xxxxxxxxxx> > Suggested-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx> > Signed-off-by: Nick Desaulniers <ndesaulniers@xxxxxxxxxx> > --- > Alternatively, we could put these in all in one variable and remove it > without any conditional checks (I think that's ok to do so with > CFLAGS_REMOVE). > > Changes v2 -> v3: > * Prefer $(CC_FLAGS_FTRACE) which is exported to -pg. > * Also check CONFIG_STACKPROTECTOR and CONFIG_STACKPROTECTOR_STRONG. > * Cc stable. > Changes v1 -> v2: > Rather than manually add -mno-sse, -mno-mmx, -mno-sse2, prefer to filter > -pg flags. > > arch/x86/purgatory/Makefile | 26 +++++++++++++++++++++----- > 1 file changed, 21 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile > index 91ef244026d2..6ef0ced59b9c 100644 > --- a/arch/x86/purgatory/Makefile > +++ b/arch/x86/purgatory/Makefile > @@ -20,11 +20,27 @@ KCOV_INSTRUMENT := n > > # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That > # in turn leaves some undefined symbols like __fentry__ in purgatory and not > -# sure how to relocate those. Like kexec-tools, use custom flags. > - > -KBUILD_CFLAGS := -fno-strict-aliasing -Wall -Wstrict-prototypes -fno-zero-initialized-in-bss -fno-builtin -ffreestanding -c -Os -mcmodel=large > -KBUILD_CFLAGS += -m$(BITS) > -KBUILD_CFLAGS += $(call cc-option,-fno-PIE) > +# sure how to relocate those. > +ifdef CONFIG_FUNCTION_TRACER > +CFLAGS_REMOVE_sha256.o += $(CC_FLAGS_FTRACE) > +CFLAGS_REMOVE_purgatory.o += $(CC_FLAGS_FTRACE) > +CFLAGS_REMOVE_string.o += $(CC_FLAGS_FTRACE) > +CFLAGS_REMOVE_kexec-purgatory.o += $(CC_FLAGS_FTRACE) > +endif > + > +ifdef CONFIG_STACKPROTECTOR > +CFLAGS_REMOVE_sha256.o += -fstack-protector > +CFLAGS_REMOVE_purgatory.o += -fstack-protector > +CFLAGS_REMOVE_string.o += -fstack-protector > +CFLAGS_REMOVE_kexec-purgatory.o += -fstack-protector > +endif > + > +ifdef CONFIG_STACKPROTECTOR_STRONG > +CFLAGS_REMOVE_sha256.o += -fstack-protector-strong > +CFLAGS_REMOVE_purgatory.o += -fstack-protector-strong > +CFLAGS_REMOVE_string.o += -fstack-protector-strong > +CFLAGS_REMOVE_kexec-purgatory.o += -fstack-protector-strong > +endif > > $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE > $(call if_changed,ld) > -- > 2.22.0.709.g102302147b-goog > Tested-by: Vaibhav Rustagi <vaibhavrustagi@xxxxxxxxxx> I tested the v3 patch series with clang compiled kernel for below scenarios: 1. kexec'ing into a new kernel. 2. Purposely crashing the running kernel to generate kdump logs. Thanks, Vaibhav