All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Dan Li <ashimida@linux.alibaba.com>
Cc: catalin.marinas@arm.com, will@kernel.org,
	ndesaulniers@google.com, keescook@chromium.org,
	masahiroy@kernel.org, tglx@linutronix.de,
	akpm@linux-foundation.org, mark.rutland@arm.com,
	samitolvanen@google.com, npiggin@gmail.com, linux@roeck-us.net,
	mhiramat@kernel.org, ojeda@kernel.org,
	luc.vanoostenryck@gmail.com, elver@google.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
Date: Wed, 23 Feb 2022 10:39:35 -0700	[thread overview]
Message-ID: <YhZxVwoshSwwJkJO@dev-arch.archlinux-ax161> (raw)
In-Reply-To: <69d351c6-a69d-6ebb-53bc-b46dfe4da08a@linux.alibaba.com>

On Wed, Feb 23, 2022 at 12:50:21AM -0800, Dan Li wrote:
> 
> 
> On 2/22/22 08:16, Nathan Chancellor wrote:
> > On Tue, Feb 22, 2022 at 01:57:36AM -0800, Dan Li wrote:
> > > Shadow call stack is available in GCC > 11.2.0, this patch makes
> > > the corresponding kernel configuration available when compiling
> > > the kernel with gcc.
> > >   config SHADOW_CALL_STACK
> > > -	bool "Clang Shadow Call Stack"
> > > -	depends on CC_IS_CLANG && ARCH_SUPPORTS_SHADOW_CALL_STACK
> > > +	bool "Shadow Call Stack"
> > > +	depends on ARCH_SUPPORTS_SHADOW_CALL_STACK
> > >   	depends on DYNAMIC_FTRACE_WITH_REGS || !FUNCTION_GRAPH_TRACER
> > >   	help
> > > -	  This option enables Clang's Shadow Call Stack, which uses a
> > > +	  This option enables Clang/GCC's Shadow Call Stack, which uses a
> > 
> > I wonder if we want to just ditch the mention of the compiler if both
> > support it?
> > 
> 
> My intention is to remind users that this is a compiler feature.
> But since there is also a hint in CC_HAVE_SHADOW_CALL_STACK:
> +# Supported by clang >= 7.0 or GCC ...
> 
> Removing the specific compiler here also looks fine to me.
> Would this look better?
> 
> "This option enables Shadow Call Stack, which uses a ..."
> 
> or maybe:
> 
> "This option enables compiler's Shadow Call Stack, which uses a ..."

I do not honestly have a strong opinion around removing mention of the
compiler so either looks fine to me (might be better to say "the
compiler's Shadow ..." in the second one).

> > >   	  shadow stack to protect function return addresses from being
> > >   	  overwritten by an attacker. More information can be found in
> > >   	  Clang's documentation:
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index 09b885cc4db5..a48a604301aa 100644
> > > --- a/arch/arm64/Kconfig
> > > +++ b/arch/arm64/Kconfig
> > > @@ -1255,7 +1255,7 @@ config HW_PERF_EVENTS
> > >   config ARCH_HAS_FILTER_PGPROT
> > >   	def_bool y
> > > -# Supported by clang >= 7.0
> > > +# Supported by clang >= 7.0 or GCC > 11.2.0
> > 
> > Same thing here, although eventually there may be a minimum GCC version
> > bump to something newer than 11.2.0, which would allow us to just drop
> > CONFIG_CC_HAVE_SHADOW_CALL_STACK altogether. No strong opinion.
> > 
> 
> As Guenter said, I thought maybe we could mark the minimum available
> version for users :)

Yes, that is what I was getting at with the "minimum version" comment.
It should remain around.

Cheers,
Nathan

WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
To: Dan Li <ashimida@linux.alibaba.com>
Cc: catalin.marinas@arm.com, will@kernel.org,
	ndesaulniers@google.com, keescook@chromium.org,
	masahiroy@kernel.org, tglx@linutronix.de,
	akpm@linux-foundation.org, mark.rutland@arm.com,
	samitolvanen@google.com, npiggin@gmail.com, linux@roeck-us.net,
	mhiramat@kernel.org, ojeda@kernel.org,
	luc.vanoostenryck@gmail.com, elver@google.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
Date: Wed, 23 Feb 2022 10:39:35 -0700	[thread overview]
Message-ID: <YhZxVwoshSwwJkJO@dev-arch.archlinux-ax161> (raw)
In-Reply-To: <69d351c6-a69d-6ebb-53bc-b46dfe4da08a@linux.alibaba.com>

On Wed, Feb 23, 2022 at 12:50:21AM -0800, Dan Li wrote:
> 
> 
> On 2/22/22 08:16, Nathan Chancellor wrote:
> > On Tue, Feb 22, 2022 at 01:57:36AM -0800, Dan Li wrote:
> > > Shadow call stack is available in GCC > 11.2.0, this patch makes
> > > the corresponding kernel configuration available when compiling
> > > the kernel with gcc.
> > >   config SHADOW_CALL_STACK
> > > -	bool "Clang Shadow Call Stack"
> > > -	depends on CC_IS_CLANG && ARCH_SUPPORTS_SHADOW_CALL_STACK
> > > +	bool "Shadow Call Stack"
> > > +	depends on ARCH_SUPPORTS_SHADOW_CALL_STACK
> > >   	depends on DYNAMIC_FTRACE_WITH_REGS || !FUNCTION_GRAPH_TRACER
> > >   	help
> > > -	  This option enables Clang's Shadow Call Stack, which uses a
> > > +	  This option enables Clang/GCC's Shadow Call Stack, which uses a
> > 
> > I wonder if we want to just ditch the mention of the compiler if both
> > support it?
> > 
> 
> My intention is to remind users that this is a compiler feature.
> But since there is also a hint in CC_HAVE_SHADOW_CALL_STACK:
> +# Supported by clang >= 7.0 or GCC ...
> 
> Removing the specific compiler here also looks fine to me.
> Would this look better?
> 
> "This option enables Shadow Call Stack, which uses a ..."
> 
> or maybe:
> 
> "This option enables compiler's Shadow Call Stack, which uses a ..."

I do not honestly have a strong opinion around removing mention of the
compiler so either looks fine to me (might be better to say "the
compiler's Shadow ..." in the second one).

> > >   	  shadow stack to protect function return addresses from being
> > >   	  overwritten by an attacker. More information can be found in
> > >   	  Clang's documentation:
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index 09b885cc4db5..a48a604301aa 100644
> > > --- a/arch/arm64/Kconfig
> > > +++ b/arch/arm64/Kconfig
> > > @@ -1255,7 +1255,7 @@ config HW_PERF_EVENTS
> > >   config ARCH_HAS_FILTER_PGPROT
> > >   	def_bool y
> > > -# Supported by clang >= 7.0
> > > +# Supported by clang >= 7.0 or GCC > 11.2.0
> > 
> > Same thing here, although eventually there may be a minimum GCC version
> > bump to something newer than 11.2.0, which would allow us to just drop
> > CONFIG_CC_HAVE_SHADOW_CALL_STACK altogether. No strong opinion.
> > 
> 
> As Guenter said, I thought maybe we could mark the minimum available
> version for users :)

Yes, that is what I was getting at with the "minimum version" comment.
It should remain around.

Cheers,
Nathan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-02-23 17:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-22  9:57 [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support Dan Li
2022-02-22  9:57 ` Dan Li
2022-02-22 16:16 ` Nathan Chancellor
2022-02-22 16:16   ` Nathan Chancellor
2022-02-22 16:47   ` Guenter Roeck
2022-02-22 16:47     ` Guenter Roeck
2022-02-22 16:59     ` Miguel Ojeda
2022-02-22 16:59       ` Miguel Ojeda
2022-02-23  8:58       ` Dan Li
2022-02-23  8:58         ` Dan Li
2022-02-23  8:55     ` Dan Li
2022-02-23  8:55       ` Dan Li
2022-02-23  8:50   ` Dan Li
2022-02-23  8:50     ` Dan Li
2022-02-23 17:39     ` Nathan Chancellor [this message]
2022-02-23 17:39       ` Nathan Chancellor
2022-02-25  0:34       ` Dan Li
2022-02-25  0:34         ` Dan Li
2022-02-22 18:47 ` Mark Rutland
2022-02-22 18:47   ` Mark Rutland
2022-02-23  9:06   ` Dan Li
2022-02-23  9:06     ` Dan Li
2022-02-23 11:48   ` Ard Biesheuvel
2022-02-23 11:48     ` Ard Biesheuvel

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=YhZxVwoshSwwJkJO@dev-arch.archlinux-ax161 \
    --to=nathan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=ashimida@linux.alibaba.com \
    --cc=catalin.marinas@arm.com \
    --cc=elver@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=llvm@lists.linux.dev \
    --cc=luc.vanoostenryck@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=npiggin@gmail.com \
    --cc=ojeda@kernel.org \
    --cc=samitolvanen@google.com \
    --cc=tglx@linutronix.de \
    --cc=will@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.