All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.