linux-hardening.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
@ 2022-02-22  9:57 Dan Li
  2022-02-22 16:16 ` Nathan Chancellor
  2022-02-22 18:47 ` Mark Rutland
  0 siblings, 2 replies; 12+ messages in thread
From: Dan Li @ 2022-02-22  9:57 UTC (permalink / raw)
  To: catalin.marinas, will, nathan, ndesaulniers, keescook, masahiroy,
	tglx, akpm, mark.rutland, samitolvanen, npiggin, linux, mhiramat,
	ojeda, luc.vanoostenryck, elver
  Cc: linux-kernel, linux-arm-kernel, llvm, linux-hardening, Dan Li

Shadow call stack is available in GCC > 11.2.0, this patch makes
the corresponding kernel configuration available when compiling
the kernel with gcc.

Note that the implementation in GCC is slightly different from Clang.
With SCS enabled, functions will only pop x30 once in the epilogue,
like:

   str     x30, [x18], #8
   stp     x29, x30, [sp, #-16]!
   ......
-  ldp     x29, x30, [sp], #16	  //clang
+  ldr     x29, [sp], #16	  //GCC
   ldr     x30, [x18, #-8]!

Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ce09ab17ddd21f73ff2caf6eec3b0ee9b0e1a11e

Signed-off-by: Dan Li <ashimida@linux.alibaba.com>
---
FYI:
This function can be used to test if the shadow call stack works:
//noinline void __noscs scs_test(void)
noinline void scs_test(void)
{
    register unsigned long *sp asm("sp");
    unsigned long * lr = sp + 1;

    asm volatile("":::"x30");
    *lr = 0;
}

ffff800008012704:       d503233f        paciasp
ffff800008012708:       f800865e        str     x30, [x18], #8
ffff80000801270c:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
ffff800008012710:       910003fd        mov     x29, sp
ffff800008012714:       910003e0        mov     x0, sp
ffff800008012718:       f900041f        str     xzr, [x0, #8]
ffff80000801271c:       f85f8e5e        ldr     x30, [x18, #-8]!
ffff800008012720:       f84107fd        ldr     x29, [sp], #16
ffff800008012724:       d50323bf        autiasp
ffff800008012728:       d65f03c0        ret

If SCS protection is enabled, this function will return normally.
If the function has __noscs attribute (scs disabled), it will crash due to 0
address access.

 arch/Kconfig                 | 6 +++---
 arch/arm64/Kconfig           | 2 +-
 include/linux/compiler-gcc.h | 4 ++++
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 678a80713b21..35db7b72bdb0 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -604,11 +604,11 @@ config ARCH_SUPPORTS_SHADOW_CALL_STACK
 	  switching.
 
 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
 	  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
 config CC_HAVE_SHADOW_CALL_STACK
 	def_bool $(cc-option, -fsanitize=shadow-call-stack -ffixed-x18)
 
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index ccbbd31b3aae..deff5b308470 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -97,6 +97,10 @@
 #define KASAN_ABI_VERSION 4
 #endif
 
+#ifdef CONFIG_SHADOW_CALL_STACK
+#define __noscs __attribute__((__no_sanitize__("shadow-call-stack")))
+#endif
+
 #if __has_attribute(__no_sanitize_address__)
 #define __no_sanitize_address __attribute__((no_sanitize_address))
 #else
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
  2022-02-22  9:57 [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support Dan Li
@ 2022-02-22 16:16 ` Nathan Chancellor
  2022-02-22 16:47   ` Guenter Roeck
  2022-02-23  8:50   ` Dan Li
  2022-02-22 18:47 ` Mark Rutland
  1 sibling, 2 replies; 12+ messages in thread
From: Nathan Chancellor @ 2022-02-22 16:16 UTC (permalink / raw)
  To: Dan Li
  Cc: catalin.marinas, will, ndesaulniers, keescook, masahiroy, tglx,
	akpm, mark.rutland, samitolvanen, npiggin, linux, mhiramat,
	ojeda, luc.vanoostenryck, elver, linux-kernel, linux-arm-kernel,
	llvm, linux-hardening

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.
> 
> Note that the implementation in GCC is slightly different from Clang.
> With SCS enabled, functions will only pop x30 once in the epilogue,
> like:
> 
>    str     x30, [x18], #8
>    stp     x29, x30, [sp, #-16]!
>    ......
> -  ldp     x29, x30, [sp], #16	  //clang
> +  ldr     x29, [sp], #16	  //GCC
>    ldr     x30, [x18, #-8]!
> 
> Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ce09ab17ddd21f73ff2caf6eec3b0ee9b0e1a11e
> 
> Signed-off-by: Dan Li <ashimida@linux.alibaba.com>

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

A few open-ended comments below.

> ---
> FYI:
> This function can be used to test if the shadow call stack works:
> //noinline void __noscs scs_test(void)
> noinline void scs_test(void)
> {
>     register unsigned long *sp asm("sp");
>     unsigned long * lr = sp + 1;
> 
>     asm volatile("":::"x30");
>     *lr = 0;
> }
> 
> ffff800008012704:       d503233f        paciasp
> ffff800008012708:       f800865e        str     x30, [x18], #8
> ffff80000801270c:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
> ffff800008012710:       910003fd        mov     x29, sp
> ffff800008012714:       910003e0        mov     x0, sp
> ffff800008012718:       f900041f        str     xzr, [x0, #8]
> ffff80000801271c:       f85f8e5e        ldr     x30, [x18, #-8]!
> ffff800008012720:       f84107fd        ldr     x29, [sp], #16
> ffff800008012724:       d50323bf        autiasp
> ffff800008012728:       d65f03c0        ret
> 
> If SCS protection is enabled, this function will return normally.
> If the function has __noscs attribute (scs disabled), it will crash due to 0
> address access.
> 
>  arch/Kconfig                 | 6 +++---
>  arch/arm64/Kconfig           | 2 +-
>  include/linux/compiler-gcc.h | 4 ++++
>  3 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 678a80713b21..35db7b72bdb0 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -604,11 +604,11 @@ config ARCH_SUPPORTS_SHADOW_CALL_STACK
>  	  switching.
>  
>  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?

>  	  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.

>  config CC_HAVE_SHADOW_CALL_STACK
>  	def_bool $(cc-option, -fsanitize=shadow-call-stack -ffixed-x18)
>  
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index ccbbd31b3aae..deff5b308470 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -97,6 +97,10 @@
>  #define KASAN_ABI_VERSION 4
>  #endif
>  
> +#ifdef CONFIG_SHADOW_CALL_STACK
> +#define __noscs __attribute__((__no_sanitize__("shadow-call-stack")))
> +#endif
> +
>  #if __has_attribute(__no_sanitize_address__)
>  #define __no_sanitize_address __attribute__((no_sanitize_address))
>  #else
> -- 
> 2.17.1
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
  2022-02-22 16:16 ` Nathan Chancellor
@ 2022-02-22 16:47   ` Guenter Roeck
  2022-02-22 16:59     ` Miguel Ojeda
  2022-02-23  8:55     ` Dan Li
  2022-02-23  8:50   ` Dan Li
  1 sibling, 2 replies; 12+ messages in thread
From: Guenter Roeck @ 2022-02-22 16:47 UTC (permalink / raw)
  To: Nathan Chancellor, Dan Li
  Cc: catalin.marinas, will, ndesaulniers, keescook, masahiroy, tglx,
	akpm, mark.rutland, samitolvanen, npiggin, mhiramat, ojeda,
	luc.vanoostenryck, elver, linux-kernel, linux-arm-kernel, llvm,
	linux-hardening

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 above suggests that the option will be available with gcc 11.3.0.
Information available in public suggests that it will be introduced
with gcc 12.0.

>> the corresponding kernel configuration available when compiling
>> the kernel with gcc.
>>
>> Note that the implementation in GCC is slightly different from Clang.
>> With SCS enabled, functions will only pop x30 once in the epilogue,
>> like:
>>
>>     str     x30, [x18], #8
>>     stp     x29, x30, [sp, #-16]!
>>     ......
>> -  ldp     x29, x30, [sp], #16	  //clang
>> +  ldr     x29, [sp], #16	  //GCC
>>     ldr     x30, [x18, #-8]!
>>
>> Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ce09ab17ddd21f73ff2caf6eec3b0ee9b0e1a11e
>>
>> Signed-off-by: Dan Li <ashimida@linux.alibaba.com>
> 
> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> 
> A few open-ended comments below.
> 
>> ---
>> FYI:
>> This function can be used to test if the shadow call stack works:
>> //noinline void __noscs scs_test(void)
>> noinline void scs_test(void)
>> {
>>      register unsigned long *sp asm("sp");
>>      unsigned long * lr = sp + 1;
>>
>>      asm volatile("":::"x30");
>>      *lr = 0;
>> }
>>
>> ffff800008012704:       d503233f        paciasp
>> ffff800008012708:       f800865e        str     x30, [x18], #8
>> ffff80000801270c:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
>> ffff800008012710:       910003fd        mov     x29, sp
>> ffff800008012714:       910003e0        mov     x0, sp
>> ffff800008012718:       f900041f        str     xzr, [x0, #8]
>> ffff80000801271c:       f85f8e5e        ldr     x30, [x18, #-8]!
>> ffff800008012720:       f84107fd        ldr     x29, [sp], #16
>> ffff800008012724:       d50323bf        autiasp
>> ffff800008012728:       d65f03c0        ret
>>
>> If SCS protection is enabled, this function will return normally.
>> If the function has __noscs attribute (scs disabled), it will crash due to 0
>> address access.
>>
>>   arch/Kconfig                 | 6 +++---
>>   arch/arm64/Kconfig           | 2 +-
>>   include/linux/compiler-gcc.h | 4 ++++
>>   3 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/Kconfig b/arch/Kconfig
>> index 678a80713b21..35db7b72bdb0 100644
>> --- a/arch/Kconfig
>> +++ b/arch/Kconfig
>> @@ -604,11 +604,11 @@ config ARCH_SUPPORTS_SHADOW_CALL_STACK
>>   	  switching.
>>   
>>   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?
> 
>>   	  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

The point here, I think, is to list the minimum gcc version.
It is going to be a long time until gcc 12.0 is the minimum version,
so I think it makes sense to list the minimum version number for
each compiler here.

However, it may make sense to add some reference indicating that
support will indeed be added with gcc 11.3.0, and not only starting
with gcc 12.0 (and maybe wait with applying this patch until it is
actually available in gcc and can be confirmed to work as intended).

Thanks,
Guenter

> 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.
> 
>>   config CC_HAVE_SHADOW_CALL_STACK
>>   	def_bool $(cc-option, -fsanitize=shadow-call-stack -ffixed-x18)
>>   
>> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
>> index ccbbd31b3aae..deff5b308470 100644
>> --- a/include/linux/compiler-gcc.h
>> +++ b/include/linux/compiler-gcc.h
>> @@ -97,6 +97,10 @@
>>   #define KASAN_ABI_VERSION 4
>>   #endif
>>   
>> +#ifdef CONFIG_SHADOW_CALL_STACK
>> +#define __noscs __attribute__((__no_sanitize__("shadow-call-stack")))
>> +#endif
>> +
>>   #if __has_attribute(__no_sanitize_address__)
>>   #define __no_sanitize_address __attribute__((no_sanitize_address))
>>   #else
>> -- 
>> 2.17.1
>>


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
  2022-02-22 16:47   ` Guenter Roeck
@ 2022-02-22 16:59     ` Miguel Ojeda
  2022-02-23  8:58       ` Dan Li
  2022-02-23  8:55     ` Dan Li
  1 sibling, 1 reply; 12+ messages in thread
From: Miguel Ojeda @ 2022-02-22 16:59 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Nathan Chancellor, Dan Li, Catalin Marinas, Will Deacon,
	Nick Desaulniers, Kees Cook, Masahiro Yamada, Thomas Gleixner,
	Andrew Morton, Mark Rutland, Sami Tolvanen, Nicholas Piggin,
	Masami Hiramatsu, Miguel Ojeda, Luc Van Oostenryck, Marco Elver,
	linux-kernel, Linux ARM, llvm, linux-hardening

On Tue, Feb 22, 2022 at 5:48 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> The point here, I think, is to list the minimum gcc version.
> It is going to be a long time until gcc 12.0 is the minimum version,
> so I think it makes sense to list the minimum version number for
> each compiler here.

Yeah, please list the minimum version (ideally `>=` instead of `>`,
with the actual version where it first appeared). It makes it easy to
then remove things that are not needed anymore when the minimum GCC
version is upgraded.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
  2022-02-22  9:57 [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support Dan Li
  2022-02-22 16:16 ` Nathan Chancellor
@ 2022-02-22 18:47 ` Mark Rutland
  2022-02-23  9:06   ` Dan Li
  2022-02-23 11:48   ` Ard Biesheuvel
  1 sibling, 2 replies; 12+ messages in thread
From: Mark Rutland @ 2022-02-22 18:47 UTC (permalink / raw)
  To: Dan Li
  Cc: catalin.marinas, will, nathan, ndesaulniers, keescook, masahiroy,
	tglx, akpm, samitolvanen, npiggin, linux, mhiramat, ojeda,
	luc.vanoostenryck, elver, linux-kernel, linux-arm-kernel, llvm,
	linux-hardening

Hi,

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.

Neat!

My local GCC devs told me that means GCC 12.x.x rather than 11.2.x or
11.3.x, so as others have said it'd be clearer to say `GCC >= 12.0.0`.

I'd like to try this with a GCC binary before I provide an Ack or R-b;
but in the mean time I have a few comments below.

> Note that the implementation in GCC is slightly different from Clang.
> With SCS enabled, functions will only pop x30 once in the epilogue,
> like:
> 
>    str     x30, [x18], #8
>    stp     x29, x30, [sp, #-16]!
>    ......
> -  ldp     x29, x30, [sp], #16	  //clang
> +  ldr     x29, [sp], #16	  //GCC
>    ldr     x30, [x18, #-8]!

Given the prologue still pushes both x29 and x30 (which we critically
depend upon) that sounds OK to me.

> 
> Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ce09ab17ddd21f73ff2caf6eec3b0ee9b0e1a11e
> 
> Signed-off-by: Dan Li <ashimida@linux.alibaba.com>
> ---
> FYI:
> This function can be used to test if the shadow call stack works:
> //noinline void __noscs scs_test(void)
> noinline void scs_test(void)
> {
>     register unsigned long *sp asm("sp");
>     unsigned long * lr = sp + 1;
> 
>     asm volatile("":::"x30");
>     *lr = 0;
> }

It's probably be better to use __builtin_frame_address(0) to get the
address of the frame record rather than assuming that fp==sp in the
middle of the function.

> ffff800008012704:       d503233f        paciasp
> ffff800008012708:       f800865e        str     x30, [x18], #8
> ffff80000801270c:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
> ffff800008012710:       910003fd        mov     x29, sp
> ffff800008012714:       910003e0        mov     x0, sp
> ffff800008012718:       f900041f        str     xzr, [x0, #8]
> ffff80000801271c:       f85f8e5e        ldr     x30, [x18, #-8]!
> ffff800008012720:       f84107fd        ldr     x29, [sp], #16
> ffff800008012724:       d50323bf        autiasp
> ffff800008012728:       d65f03c0        ret
> 
> If SCS protection is enabled, this function will return normally.
> If the function has __noscs attribute (scs disabled), it will crash due to 0
> address access.
> 
>  arch/Kconfig                 | 6 +++---
>  arch/arm64/Kconfig           | 2 +-
>  include/linux/compiler-gcc.h | 4 ++++
>  3 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 678a80713b21..35db7b72bdb0 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -604,11 +604,11 @@ config ARCH_SUPPORTS_SHADOW_CALL_STACK
>  	  switching.
>  
>  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
>  	  shadow stack to protect function return addresses from being
>  	  overwritten by an attacker. More information can be found in
>  	  Clang's documentation:

Is there any additional GCC documentation that we can refer to?

> 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

As above, I beleive that should be `GCC >= 12.0.0`.

Thanks,
Mark

>  config CC_HAVE_SHADOW_CALL_STACK
>  	def_bool $(cc-option, -fsanitize=shadow-call-stack -ffixed-x18)
>  
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index ccbbd31b3aae..deff5b308470 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -97,6 +97,10 @@
>  #define KASAN_ABI_VERSION 4
>  #endif
>  
> +#ifdef CONFIG_SHADOW_CALL_STACK
> +#define __noscs __attribute__((__no_sanitize__("shadow-call-stack")))
> +#endif
> +
>  #if __has_attribute(__no_sanitize_address__)
>  #define __no_sanitize_address __attribute__((no_sanitize_address))
>  #else
> -- 
> 2.17.1
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
  2022-02-22 16:16 ` Nathan Chancellor
  2022-02-22 16:47   ` Guenter Roeck
@ 2022-02-23  8:50   ` Dan Li
  2022-02-23 17:39     ` Nathan Chancellor
  1 sibling, 1 reply; 12+ messages in thread
From: Dan Li @ 2022-02-23  8:50 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: catalin.marinas, will, ndesaulniers, keescook, masahiroy, tglx,
	akpm, mark.rutland, samitolvanen, npiggin, linux, mhiramat,
	ojeda, luc.vanoostenryck, elver, linux-kernel, linux-arm-kernel,
	llvm, linux-hardening



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 ..."

>>   	  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 :)

Thanks,
Dan.


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
  2022-02-22 16:47   ` Guenter Roeck
  2022-02-22 16:59     ` Miguel Ojeda
@ 2022-02-23  8:55     ` Dan Li
  1 sibling, 0 replies; 12+ messages in thread
From: Dan Li @ 2022-02-23  8:55 UTC (permalink / raw)
  To: Guenter Roeck, Nathan Chancellor
  Cc: catalin.marinas, will, ndesaulniers, keescook, masahiroy, tglx,
	akpm, mark.rutland, samitolvanen, npiggin, mhiramat, ojeda,
	luc.vanoostenryck, elver, linux-kernel, linux-arm-kernel, llvm,
	linux-hardening



On 2/22/22 08:47, Guenter Roeck 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 above suggests that the option will be available with gcc 11.3.0.
> Information available in public suggests that it will be introduced
> with gcc 12.0.
> 

Ah, yes, I think we could use "gcc >= 12.0.0" here.

> The point here, I think, is to list the minimum gcc version.
> It is going to be a long time until gcc 12.0 is the minimum version,
> so I think it makes sense to list the minimum version number for
> each compiler here.
> 
> However, it may make sense to add some reference indicating that
> support will indeed be added with gcc 11.3.0, and not only starting

I took a quick look at the gcc description, and it seems like the
y in x.y.z is usually used to fix bugs, and new features should be
added directly to the trunk.

Link: https://gcc.gnu.org/develop.html

> with gcc 12.0 (and maybe wait with applying this patch until it is
> actually available in gcc and can be confirmed to work as intended).
> 

It's also fine to wait for gcc 12 to be released, and I thought maybe
I could submit the "final" version of this patch to the community (or
mailing list) first so maybe more people would test it and if there
were any issues, it could be fixed before GCC 12 is released :)

Thanks,
Dan.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
  2022-02-22 16:59     ` Miguel Ojeda
@ 2022-02-23  8:58       ` Dan Li
  0 siblings, 0 replies; 12+ messages in thread
From: Dan Li @ 2022-02-23  8:58 UTC (permalink / raw)
  To: Miguel Ojeda, Guenter Roeck
  Cc: Nathan Chancellor, Catalin Marinas, Will Deacon,
	Nick Desaulniers, Kees Cook, Masahiro Yamada, Thomas Gleixner,
	Andrew Morton, Mark Rutland, Sami Tolvanen, Nicholas Piggin,
	Masami Hiramatsu, Miguel Ojeda, Luc Van Oostenryck, Marco Elver,
	linux-kernel, Linux ARM, llvm, linux-hardening



On 2/22/22 08:59, Miguel Ojeda wrote:
> On Tue, Feb 22, 2022 at 5:48 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> The point here, I think, is to list the minimum gcc version.
>> It is going to be a long time until gcc 12.0 is the minimum version,
>> so I think it makes sense to list the minimum version number for
>> each compiler here.
> 
> Yeah, please list the minimum version (ideally `>=` instead of `>`,
> with the actual version where it first appeared). It makes it easy to
> then remove things that are not needed anymore when the minimum GCC
> version is upgraded.
> 

Got it, I'll use "gcc >= 12.0.0" in the next patch.

Thanks,
Dan.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
  2022-02-22 18:47 ` Mark Rutland
@ 2022-02-23  9:06   ` Dan Li
  2022-02-23 11:48   ` Ard Biesheuvel
  1 sibling, 0 replies; 12+ messages in thread
From: Dan Li @ 2022-02-23  9:06 UTC (permalink / raw)
  To: Mark Rutland
  Cc: catalin.marinas, will, nathan, ndesaulniers, keescook, masahiroy,
	tglx, akpm, samitolvanen, npiggin, linux, mhiramat, ojeda,
	luc.vanoostenryck, elver, linux-kernel, linux-arm-kernel, llvm,
	linux-hardening



On 2/22/22 10:47, Mark Rutland wrote:
> Hi,
> 
> 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.
> 
> Neat!
> 
> My local GCC devs told me that means GCC 12.x.x rather than 11.2.x or
> 11.3.x, so as others have said it'd be clearer to say `GCC >= 12.0.0`.
> 

Ah, yes, I just saw this flag in gcc/BASE-VER.

> I'd like to try this with a GCC binary before I provide an Ack or R-b;
> but in the mean time I have a few comments below.
> 

Thanks for your test, Mark.
Please let me know if there is any issues :)

>> ---
>> FYI:
>> This function can be used to test if the shadow call stack works:
>> //noinline void __noscs scs_test(void)
>> noinline void scs_test(void)
>> {
>>      register unsigned long *sp asm("sp");
>>      unsigned long * lr = sp + 1;
>>
>>      asm volatile("":::"x30");
>>      *lr = 0;
>> }
> 
> It's probably be better to use __builtin_frame_address(0) to get the
> address of the frame record rather than assuming that fp==sp in the
> middle of the function.
> 

Got it.

>>   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
>>   	  shadow stack to protect function return addresses from being
>>   	  overwritten by an attacker. More information can be found in
>>   	  Clang's documentation:
> 
> Is there any additional GCC documentation that we can refer to?
> 

Currently there is only a brief description of
-fsanitize=shadow-call-stack in the user manual.

Since the description of the clang documentation is more detailed, should
I add this gcc link to the configuration description?

Link: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#Instrumentation-Options

>> 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
> 
> As above, I beleive that should be `GCC >= 12.0.0`.
> 

Yeah.

Thanks,
Dan.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
  2022-02-22 18:47 ` Mark Rutland
  2022-02-23  9:06   ` Dan Li
@ 2022-02-23 11:48   ` Ard Biesheuvel
  1 sibling, 0 replies; 12+ messages in thread
From: Ard Biesheuvel @ 2022-02-23 11:48 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Dan Li, Catalin Marinas, Will Deacon, Nathan Chancellor,
	Nick Desaulniers, Kees Cook, Masahiro Yamada, Thomas Gleixner,
	Andrew Morton, Sami Tolvanen, Nicholas Piggin, Guenter Roeck,
	Masami Hiramatsu, Miguel Ojeda, luc.vanoostenryck, Marco Elver,
	Linux Kernel Mailing List, Linux ARM, llvm, linux-hardening

On Tue, 22 Feb 2022 at 19:48, Mark Rutland <mark.rutland@arm.com> wrote:
>
> Hi,
>
> 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.
>
> Neat!
>
> My local GCC devs told me that means GCC 12.x.x rather than 11.2.x or
> 11.3.x, so as others have said it'd be clearer to say `GCC >= 12.0.0`.
>
> I'd like to try this with a GCC binary before I provide an Ack or R-b;
> but in the mean time I have a few comments below.
>
> > Note that the implementation in GCC is slightly different from Clang.
> > With SCS enabled, functions will only pop x30 once in the epilogue,
> > like:
> >
> >    str     x30, [x18], #8
> >    stp     x29, x30, [sp, #-16]!
> >    ......
> > -  ldp     x29, x30, [sp], #16          //clang
> > +  ldr     x29, [sp], #16       //GCC
> >    ldr     x30, [x18, #-8]!
>
> Given the prologue still pushes both x29 and x30 (which we critically
> depend upon) that sounds OK to me.
>

Indeed.

What did come up in the discussion on the GCC side was runtime
patching (to avoid the overhead of having both PAC and SCS), but it
seems far more likely that we would patch PACIASP/AUTIASP instructions
into SCS pushes/pops rather than the other way around, and so loading
x30 only once should be fine.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
  2022-02-23  8:50   ` Dan Li
@ 2022-02-23 17:39     ` Nathan Chancellor
  2022-02-25  0:34       ` Dan Li
  0 siblings, 1 reply; 12+ messages in thread
From: Nathan Chancellor @ 2022-02-23 17:39 UTC (permalink / raw)
  To: Dan Li
  Cc: catalin.marinas, will, ndesaulniers, keescook, masahiroy, tglx,
	akpm, mark.rutland, samitolvanen, npiggin, linux, mhiramat,
	ojeda, luc.vanoostenryck, elver, linux-kernel, linux-arm-kernel,
	llvm, linux-hardening

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support
  2022-02-23 17:39     ` Nathan Chancellor
@ 2022-02-25  0:34       ` Dan Li
  0 siblings, 0 replies; 12+ messages in thread
From: Dan Li @ 2022-02-25  0:34 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: catalin.marinas, will, ndesaulniers, keescook, masahiroy, tglx,
	akpm, mark.rutland, samitolvanen, npiggin, linux, mhiramat,
	ojeda, luc.vanoostenryck, elver, linux-kernel, linux-arm-kernel,
	llvm, linux-hardening



On 2/23/22 09:39, Nathan Chancellor wrote:
> On Wed, Feb 23, 2022 at 12:50:21AM -0800, Dan Li wrote:
>> 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).
> 

Ah, yes, thanks :)

Dan.

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2022-02-25  0:35 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-22  9:57 [PATCH] [PATCH] AARCH64: Add gcc Shadow Call Stack support Dan Li
2022-02-22 16:16 ` Nathan Chancellor
2022-02-22 16:47   ` Guenter Roeck
2022-02-22 16:59     ` Miguel Ojeda
2022-02-23  8:58       ` Dan Li
2022-02-23  8:55     ` Dan Li
2022-02-23  8:50   ` Dan Li
2022-02-23 17:39     ` Nathan Chancellor
2022-02-25  0:34       ` Dan Li
2022-02-22 18:47 ` Mark Rutland
2022-02-23  9:06   ` Dan Li
2022-02-23 11:48   ` Ard Biesheuvel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).