From: Masahiro Yamada <masahiroy@kernel.org> To: Kees Cook <keescook@chromium.org> Cc: Peter Zijlstra <peterz@infradead.org>, Thomas Gleixner <tglx@linutronix.de>, X86 ML <x86@kernel.org>, Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] kbuild: Provide way to actually disable stack protector Date: Sat, 27 Jun 2020 04:04:33 +0900 [thread overview] Message-ID: <CAK7LNARRU7j_aSgZreuR-jyFYAipaJwZjUwzmE9RcohgKJvS8w@mail.gmail.com> (raw) In-Reply-To: <202006222234.FBCEAD7F@keescook> On Tue, Jun 23, 2020 at 2:37 PM Kees Cook <keescook@chromium.org> wrote: > > On Tue, Jun 23, 2020 at 11:33:53AM +0900, Masahiro Yamada wrote: > > On Tue, Jun 23, 2020 at 4:02 AM Kees Cook <keescook@chromium.org> wrote: > > > > > > Some builds of GCC enable stack protector by default. Simply removing > > > the arguments is not sufficient to disable stack protector, as the stack > > > protector for those GCC builds must be explicitly disabled. (Removing the > > > arguments is left as-is just to be sure there are no ordering problems. If > > > -fno-stack-protector ended up _before_ -fstack-protector, it would not > > > disable it: GCC uses whichever -f... comes last on the command line.) > > > > > > Fixes: 20355e5f73a7 ("x86/entry: Exclude low level entry code from sanitizing") > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > > --- > > > Makefile | 4 +++- > > > arch/Kconfig | 3 --- > > > arch/arm/boot/compressed/Makefile | 4 ++-- > > > arch/x86/entry/Makefile | 3 +++ > > > 4 files changed, 8 insertions(+), 6 deletions(-) > > > > > > diff --git a/Makefile b/Makefile > > > index ac2c61c37a73..b46e91bf0b0e 100644 > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -762,7 +762,9 @@ ifneq ($(CONFIG_FRAME_WARN),0) > > > KBUILD_CFLAGS += -Wframe-larger-than=$(CONFIG_FRAME_WARN) > > > endif > > > > > > -stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector > > > +DISABLE_STACKPROTECTOR := $(call cc-option,-fno-stack-protector) > > > +export DISABLE_STACKPROTECTOR > > > +stackp-flags-y := $(DISABLE_STACKPROTECTOR) > > > stackp-flags-$(CONFIG_STACKPROTECTOR) := -fstack-protector > > > stackp-flags-$(CONFIG_STACKPROTECTOR_STRONG) := -fstack-protector-strong > > > > > > diff --git a/arch/Kconfig b/arch/Kconfig > > > index 8cc35dc556c7..1ea61290900a 100644 > > > --- a/arch/Kconfig > > > +++ b/arch/Kconfig > > > @@ -478,9 +478,6 @@ config HAVE_STACKPROTECTOR > > > An arch should select this symbol if: > > > - it has implemented a stack canary (e.g. __stack_chk_guard) > > > > > > -config CC_HAS_STACKPROTECTOR_NONE > > > - def_bool $(cc-option,-fno-stack-protector) > > > - > > > config STACKPROTECTOR > > > bool "Stack Protector buffer overflow detection" > > > depends on HAVE_STACKPROTECTOR > > > diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile > > > index 00602a6fba04..3693bac525d2 100644 > > > --- a/arch/arm/boot/compressed/Makefile > > > +++ b/arch/arm/boot/compressed/Makefile > > > @@ -84,9 +84,9 @@ endif > > > > > > # -fstack-protector-strong triggers protection checks in this code, > > > # but it is being used too early to link to meaningful stack_chk logic. > > > -nossp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector > > > $(foreach o, $(libfdt_objs) atags_to_fdt.o, \ > > > - $(eval CFLAGS_$(o) := -I $(srctree)/scripts/dtc/libfdt $(nossp-flags-y))) > > > + $(eval CFLAGS_$(o) := -I $(srctree)/scripts/dtc/libfdt \ > > > + $(DISABLE_STACKPROTECTOR))) > > > > > > # These were previously generated C files. When you are building the kernel > > > # with O=, make sure to remove the stale files in the output tree. Otherwise, > > > diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile > > > index b7a5790d8d63..79902decc3d1 100644 > > > --- a/arch/x86/entry/Makefile > > > +++ b/arch/x86/entry/Makefile > > > @@ -10,6 +10,9 @@ KCOV_INSTRUMENT := n > > > CFLAGS_REMOVE_common.o = $(CC_FLAGS_FTRACE) -fstack-protector -fstack-protector-strong > > > CFLAGS_REMOVE_syscall_32.o = $(CC_FLAGS_FTRACE) -fstack-protector -fstack-protector-strong > > > CFLAGS_REMOVE_syscall_64.o = $(CC_FLAGS_FTRACE) -fstack-protector -fstack-protector-strong > > > +CFLAGS_common.o += $(DISABLE_STACKPROTECTOR) > > > +CFLAGS_syscall_32.o += $(DISABLE_STACKPROTECTOR) > > > +CFLAGS_syscall_64.o += $(DISABLE_STACKPROTECTOR) > > > > There is one more c file in this directory. > > > > Is it OK to not patch syscall_x32.c ? > > Good question. Peter? (It seems all the syscall_*.c files are just a > table, not code -- why do they need any instrumentation changes?) > > > > > > > > > > > CFLAGS_syscall_64.o += $(call cc-option,-Wno-override-init,) > > > CFLAGS_syscall_32.o += $(call cc-option,-Wno-override-init,) > > > > > > > > > > This patch is ugly. > > > > I'd rather want to fix this by one-liner. > > Why not a global export to assist? This isn't the only place it's needed > (see the arm64 chunk...) Is it useful when we know DISABLE_STACKPROTECTOR = -fno-stack-protector ? I'd rather want to apply this patch https://patchwork.kernel.org/patch/11628493/ and hard-code -fno-stack-protector where necessary. > > > > > > > > > > > diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile > > index b7a5790d8d63..0d41eb91aaea 100644 > > --- a/arch/x86/entry/Makefile > > +++ b/arch/x86/entry/Makefile > > @@ -11,6 +11,8 @@ CFLAGS_REMOVE_common.o = $(CC_FLAGS_FTRACE) > > -fstack-protector -fstack-protector- > > CFLAGS_REMOVE_syscall_32.o = $(CC_FLAGS_FTRACE) -fstack-protector > > -fstack-protector-strong > > CFLAGS_REMOVE_syscall_64.o = $(CC_FLAGS_FTRACE) -fstack-protector > > -fstack-protector-strong > > > > +ccflags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) += -fno-stack-protector > > + > > Order matters here -- when is ccflags-y applied? cc-flags-y comes after KBUILD_CFLAGS so that -fno-stack-protector can negate -fstack-protector(-strong) > > > CFLAGS_syscall_64.o += $(call cc-option,-Wno-override-init,) > > CFLAGS_syscall_32.o += $(call cc-option,-Wno-override-init,) > > obj-y := entry_$(BITS).o thunk_$(BITS).o > > syscall_$(BITS).o > > > > > > > > > > -- > > Best Regards > > Masahiro Yamada > > -- > Kees Cook -- Best Regards Masahiro Yamada
WARNING: multiple messages have this Message-ID (diff)
From: Masahiro Yamada <masahiroy@kernel.org> To: Kees Cook <keescook@chromium.org> Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, X86 ML <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH] kbuild: Provide way to actually disable stack protector Date: Sat, 27 Jun 2020 04:04:33 +0900 [thread overview] Message-ID: <CAK7LNARRU7j_aSgZreuR-jyFYAipaJwZjUwzmE9RcohgKJvS8w@mail.gmail.com> (raw) In-Reply-To: <202006222234.FBCEAD7F@keescook> On Tue, Jun 23, 2020 at 2:37 PM Kees Cook <keescook@chromium.org> wrote: > > On Tue, Jun 23, 2020 at 11:33:53AM +0900, Masahiro Yamada wrote: > > On Tue, Jun 23, 2020 at 4:02 AM Kees Cook <keescook@chromium.org> wrote: > > > > > > Some builds of GCC enable stack protector by default. Simply removing > > > the arguments is not sufficient to disable stack protector, as the stack > > > protector for those GCC builds must be explicitly disabled. (Removing the > > > arguments is left as-is just to be sure there are no ordering problems. If > > > -fno-stack-protector ended up _before_ -fstack-protector, it would not > > > disable it: GCC uses whichever -f... comes last on the command line.) > > > > > > Fixes: 20355e5f73a7 ("x86/entry: Exclude low level entry code from sanitizing") > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > > --- > > > Makefile | 4 +++- > > > arch/Kconfig | 3 --- > > > arch/arm/boot/compressed/Makefile | 4 ++-- > > > arch/x86/entry/Makefile | 3 +++ > > > 4 files changed, 8 insertions(+), 6 deletions(-) > > > > > > diff --git a/Makefile b/Makefile > > > index ac2c61c37a73..b46e91bf0b0e 100644 > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -762,7 +762,9 @@ ifneq ($(CONFIG_FRAME_WARN),0) > > > KBUILD_CFLAGS += -Wframe-larger-than=$(CONFIG_FRAME_WARN) > > > endif > > > > > > -stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector > > > +DISABLE_STACKPROTECTOR := $(call cc-option,-fno-stack-protector) > > > +export DISABLE_STACKPROTECTOR > > > +stackp-flags-y := $(DISABLE_STACKPROTECTOR) > > > stackp-flags-$(CONFIG_STACKPROTECTOR) := -fstack-protector > > > stackp-flags-$(CONFIG_STACKPROTECTOR_STRONG) := -fstack-protector-strong > > > > > > diff --git a/arch/Kconfig b/arch/Kconfig > > > index 8cc35dc556c7..1ea61290900a 100644 > > > --- a/arch/Kconfig > > > +++ b/arch/Kconfig > > > @@ -478,9 +478,6 @@ config HAVE_STACKPROTECTOR > > > An arch should select this symbol if: > > > - it has implemented a stack canary (e.g. __stack_chk_guard) > > > > > > -config CC_HAS_STACKPROTECTOR_NONE > > > - def_bool $(cc-option,-fno-stack-protector) > > > - > > > config STACKPROTECTOR > > > bool "Stack Protector buffer overflow detection" > > > depends on HAVE_STACKPROTECTOR > > > diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile > > > index 00602a6fba04..3693bac525d2 100644 > > > --- a/arch/arm/boot/compressed/Makefile > > > +++ b/arch/arm/boot/compressed/Makefile > > > @@ -84,9 +84,9 @@ endif > > > > > > # -fstack-protector-strong triggers protection checks in this code, > > > # but it is being used too early to link to meaningful stack_chk logic. > > > -nossp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector > > > $(foreach o, $(libfdt_objs) atags_to_fdt.o, \ > > > - $(eval CFLAGS_$(o) := -I $(srctree)/scripts/dtc/libfdt $(nossp-flags-y))) > > > + $(eval CFLAGS_$(o) := -I $(srctree)/scripts/dtc/libfdt \ > > > + $(DISABLE_STACKPROTECTOR))) > > > > > > # These were previously generated C files. When you are building the kernel > > > # with O=, make sure to remove the stale files in the output tree. Otherwise, > > > diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile > > > index b7a5790d8d63..79902decc3d1 100644 > > > --- a/arch/x86/entry/Makefile > > > +++ b/arch/x86/entry/Makefile > > > @@ -10,6 +10,9 @@ KCOV_INSTRUMENT := n > > > CFLAGS_REMOVE_common.o = $(CC_FLAGS_FTRACE) -fstack-protector -fstack-protector-strong > > > CFLAGS_REMOVE_syscall_32.o = $(CC_FLAGS_FTRACE) -fstack-protector -fstack-protector-strong > > > CFLAGS_REMOVE_syscall_64.o = $(CC_FLAGS_FTRACE) -fstack-protector -fstack-protector-strong > > > +CFLAGS_common.o += $(DISABLE_STACKPROTECTOR) > > > +CFLAGS_syscall_32.o += $(DISABLE_STACKPROTECTOR) > > > +CFLAGS_syscall_64.o += $(DISABLE_STACKPROTECTOR) > > > > There is one more c file in this directory. > > > > Is it OK to not patch syscall_x32.c ? > > Good question. Peter? (It seems all the syscall_*.c files are just a > table, not code -- why do they need any instrumentation changes?) > > > > > > > > > > > CFLAGS_syscall_64.o += $(call cc-option,-Wno-override-init,) > > > CFLAGS_syscall_32.o += $(call cc-option,-Wno-override-init,) > > > > > > > > > > This patch is ugly. > > > > I'd rather want to fix this by one-liner. > > Why not a global export to assist? This isn't the only place it's needed > (see the arm64 chunk...) Is it useful when we know DISABLE_STACKPROTECTOR = -fno-stack-protector ? I'd rather want to apply this patch https://patchwork.kernel.org/patch/11628493/ and hard-code -fno-stack-protector where necessary. > > > > > > > > > > > diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile > > index b7a5790d8d63..0d41eb91aaea 100644 > > --- a/arch/x86/entry/Makefile > > +++ b/arch/x86/entry/Makefile > > @@ -11,6 +11,8 @@ CFLAGS_REMOVE_common.o = $(CC_FLAGS_FTRACE) > > -fstack-protector -fstack-protector- > > CFLAGS_REMOVE_syscall_32.o = $(CC_FLAGS_FTRACE) -fstack-protector > > -fstack-protector-strong > > CFLAGS_REMOVE_syscall_64.o = $(CC_FLAGS_FTRACE) -fstack-protector > > -fstack-protector-strong > > > > +ccflags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) += -fno-stack-protector > > + > > Order matters here -- when is ccflags-y applied? cc-flags-y comes after KBUILD_CFLAGS so that -fno-stack-protector can negate -fstack-protector(-strong) > > > CFLAGS_syscall_64.o += $(call cc-option,-Wno-override-init,) > > CFLAGS_syscall_32.o += $(call cc-option,-Wno-override-init,) > > obj-y := entry_$(BITS).o thunk_$(BITS).o > > syscall_$(BITS).o > > > > > > > > > > -- > > Best Regards > > Masahiro Yamada > > -- > Kees Cook -- Best Regards Masahiro Yamada _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-06-26 19:05 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-22 19:02 [PATCH] kbuild: Provide way to actually disable stack protector Kees Cook 2020-06-23 2:33 ` Masahiro Yamada 2020-06-23 5:37 ` Kees Cook 2020-06-26 19:04 ` Masahiro Yamada [this message] 2020-06-26 19:04 ` Masahiro Yamada 2020-06-26 20:18 ` Kees Cook 2020-06-26 20:18 ` Kees Cook
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAK7LNARRU7j_aSgZreuR-jyFYAipaJwZjUwzmE9RcohgKJvS8w@mail.gmail.com \ --to=masahiroy@kernel.org \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=peterz@infradead.org \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.