ARM64: SCS: Add gcc plugin to support Shadow Call Stack

- This function can be used to test whether the shadow stack is effective:
//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;
}

when compiled with:
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_ARM64_PTR_AUTH_KERNEL=y
CONFIG_ARM64_BTI_KERNEL=y

ffff800010013b60 <scs_test>:

ffff800010013b60:       d503245f        bti     c
ffff800010013b64:       d503201f        nop
ffff800010013b68:       d503201f        nop
ffff800010013b6c:       d503233f        paciasp
ffff800010013b70:       f800865e        str     x30, [x18], #8
ffff800010013b74:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
ffff800010013b78:       910003fd        mov     x29, sp
ffff800010013b7c:       910003e0        mov     x0, sp
ffff800010013b80:       f900041f        str     xzr, [x0, #8]
ffff800010013b84:       a8c17bfd        ldp     x29, x30, [sp], #16
ffff800010013b88:       f85f8e5e        ldr     x30, [x18, #-8]!
ffff800010013b8c:       d50323bf        autiasp
ffff800010013b90:       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.

include/linux/compiler-gcc.h +0 -0

index cb9217f..426c8e5 100644

Quoted 6 lines · Dan Li

include/linux/compiler-gcc.h +0 -0

@@ -50,6 +50,10 @@
  #define __latent_entropy __attribute__((latent_entropy))
  #endif
 

include/linux/compiler-gcc.h line 55

Quoted 3 lines

include/linux/compiler-gcc.h +3 -0

+#if defined(SHADOW_CALL_STACK_PLUGIN) && !defined(__CHECKER__)
+#define __noscs __attribute__((no_shadow_call_stack))
+#endif

Cool this is a nice addition, and something I don't think that clang has. For any new feature, having a function attribute to disable it at the function granularity is nice, and plays better with LTO than -f group flags. Though that begs the question: what happens if a __noscs callee is inlined into a non-__noscs caller, or vice versa?

I noticed that __noscs isn't actually applied anywhere in the kernel, yet, at least in this series. Were there any places necessary that you've found thus far?

Overall, I'm happy with the patch and am ready to ack it, but I would like to see a link to to the upstream GCC feature request for SCS (and one created if it doesn't exist) cited explicitly in the commit message. I think that would be a good demonstration that this can or will be upstreamed into the compiler proper for the compiler vendors to maintain, rather than the kernel folks. The compiler vendors may have further feedback on the approach, such as my question above pertaining to inlining.

Quoted 9 lines · Nick Desaulniers

Overall, I'm happy with the patch and am ready to ack it, but I would like to see a link to to the upstream GCC feature request for SCS (and one created if it doesn't exist) cited explicitly in the commit message. I think that would be a good demonstration that this can or will be upstreamed into the compiler proper for the compiler vendors to maintain, rather than the kernel folks. The compiler vendors may have further feedback on the approach, such as my question above pertaining to inlining.

I have submitted a feature request to the gcc community, and waiting for a follow-up response.

Is it fine to add the following description in [PATCH V5]?

A similar feature request has also been sent to gcc.

link https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102768

Quoted 7 lines · Nick Desaulniers

Quoted 6 lines · Dan Li

include/linux/compiler-gcc.h +0 -0

@@ -50,6 +50,10 @@
  #define __latent_entropy __attribute__((latent_entropy))
  #endif
 

Quoted 9 lines

include/linux/compiler-gcc.h line 55

Quoted 3 lines

include/linux/compiler-gcc.h +3 -0

+#if defined(SHADOW_CALL_STACK_PLUGIN) && !defined(__CHECKER__)
+#define __noscs __attribute__((no_shadow_call_stack))
+#endif

Cool this is a nice addition, and something I don't think that clang has. For any new feature, having a function attribute to disable it at the function granularity is nice, and plays better with LTO than -f group flags. Though that begs the question: what happens if a __noscs callee is inlined into a non-__noscs caller, or vice versa?

Thanks Nick,

According to my understanding, all inline optimizations in gcc should happen before inserting scs insns (scs and paciasp/autiasp use the same insertion point). Therefore, the check for the __noscs attribute will also occur after all inlining is completed.

As in the following example:
- Since __noscs attribute is specified, scs_test1 does not insert scs insns
- Since normal functions scs_test2/3 uses x30, it needs to insert scs insns
- Since __noscs attribute is specified, scs_test4 after inlining does not need to insert scs insns

__always_inline __noscs void scs_test1(void)

{
     asm volatile("mov x1, x1\n\t":::"x30");
}

//scs insns inserted after function inline
void scs_test2(void)

{
     scs_test1();
}

__always_inline void scs_test3(void)

{
     asm volatile("mov x3, x3\n\t":::"x30");
}

//no scs insns inserted
__noscs void scs_test4(void)

{
     scs_test3();
}

ffff800010012900 <scs_test1>:

ffff800010012900:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
ffff800010012904:       910003fd        mov     x29, sp
ffff800010012908:       aa0103e1        mov     x1, x1
ffff80001001290c:       a8c17bfd        ldp     x29, x30, [sp], #16
ffff800010012910:       d65f03c0        ret

ffff800010012914 <scs_test2>:

ffff800010012914:       f800865e        str     x30, [x18], #8
ffff800010012918:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
ffff80001001291c:       910003fd        mov     x29, sp
ffff800010012920:       aa0103e1        mov     x1, x1
ffff800010012924:       a8c17bfd        ldp     x29, x30, [sp], #16
ffff800010012928:       f85f8e5e        ldr     x30, [x18, #-8]!
ffff80001001292c:       d65f03c0        ret

ffff800010012930 <scs_test3>:

ffff800010012930:       f800865e        str     x30, [x18], #8
ffff800010012934:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
ffff800010012938:       910003fd        mov     x29, sp
ffff80001001293c:       aa0303e3        mov     x3, x3
ffff800010012940:       a8c17bfd        ldp     x29, x30, [sp], #16
ffff800010012944:       f85f8e5e        ldr     x30, [x18, #-8]!
ffff800010012948:       d65f03c0        ret
ffff80001001294c:       d503201f        nop

ffff800010012950 <scs_test4>:

ffff800010012950:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
ffff800010012954:       910003fd        mov     x29, sp
ffff800010012958:       aa0303e3        mov     x3, x3
ffff80001001295c:       a8c17bfd        ldp     x29, x30, [sp], #16
ffff800010012960:       d65f03c0        ret

Quoted 3 lines

I noticed that __noscs isn't actually applied anywhere in the kernel, yet, at least in this series. Were there any places necessary that you've found thus far?

At present, I have not found a function that must use the __noscs attribute in the kernel. I have only used this attribute in test cases.

Quoted 38 lines · Dan Li

Quoted 7 lines · Nick Desaulniers

Quoted 6 lines · Dan Li

include/linux/compiler-gcc.h +0 -0

@@ -50,6 +50,10 @@
   #define __latent_entropy __attribute__((latent_entropy))
   #endif
 

Quoted 9 lines

include/linux/compiler-gcc.h line 55

Quoted 3 lines

include/linux/compiler-gcc.h +3 -0

+#if defined(SHADOW_CALL_STACK_PLUGIN) && !defined(__CHECKER__)
+#define __noscs __attribute__((no_shadow_call_stack))
+#endif

Cool this is a nice addition, and something I don't think that clang has. For any new feature, having a function attribute to disable it at the function granularity is nice, and plays better with LTO than -f group flags. Though that begs the question: what happens if a __noscs callee is inlined into a non-__noscs caller, or vice versa?

Thanks Nick,

According to my understanding, all inline optimizations in gcc should happen before inserting scs insns (scs and paciasp/autiasp use the same insertion point). Therefore, the check for the __noscs attribute will also occur after all inlining is completed.

As in the following example:
- Since __noscs attribute is specified, scs_test1 does not insert scs insns
- Since normal functions scs_test2/3 uses x30, it needs to insert scs insns
- Since __noscs attribute is specified, scs_test4 after inlining does not need to insert scs insns

__always_inline __noscs void scs_test1(void)

{
      asm volatile("mov x1, x1\n\t":::"x30");
}

Quoted 5 lines

//scs insns inserted after function inline
void scs_test2(void)

{
      scs_test1();
}

That may be surprising to developers. Perhaps __always_inline on scs_test1 is distracting this test case, but I suspect it may not make a difference. This particular issue comes up time and again with stack protectors; ie. the callee is marked no stack protector, then gets inlined into a caller and suddenly gets a stack protector.