The Linux kernel built with Clang already supports ShadowCallStack (SCS) in version 5.8. ShadowCallStack is an LLVM instrumentation mode that saves the return address of a function to a separate allocation in the function prolog of a non-leaf function ShadowCallStack, and load the return address from the ShadowCallStack in the function epilog, thus preventing return address overwriting (such as stack buffer overflow). Return addresses are also stored on the regular stack for compatibility with unwinders, but otherwise serve no purpose. This ensures that the attack (modification of the return address on the normal stack) does not have any impact on program control flow.

On aarch64, this instrumentation mechanism usesx18Register to reference the ShadowCallStack, which means that the reference to the ShadowCallStack does not have to be stored in memory. Therefore, the implemented runtime avoids exposing the ShadowCallStack address to an attacker who can read arbitrary memory.

Linux 6.2 currently in development Implementing a dynamic ShadowCallStackto avoid SCS overhead on processors that support Pointer Authentication (PAC).

As mentioned above, ShadowCallStack is useful for preventing return address overwrites such as stack buffer overflows. But on an AArch64 processor with pointer authentication, it’s hard to justify the usefulness of SCS. So for Linux 6.2, it is planned to enable dynamic SCS support, allowing it to be enabled/disabled at boot time. This dynamic SCS support feature is implemented through code patching at startup/runtime.

Therefore, for those users who do not want to provide this security feature for their AArch64 SoCs due to other hardware protections already in place, there is no need for an alternate kernel build with SCS disabled. The code to implement dynamic SCS support for ARM64 via Clang will be committed to the Linux 6.2 merge window next month if nothing goes wrong.