[PATCH v5 0/3] arm64: dynamic shadow call stack support

[Kees Cook]

On Mon, Aug 22, 2022 at 11:50:55AM +0200, Ard Biesheuvel wrote:
> Generic kernel images such as Android's GKI usually enable all available
> security features, which are typically implemented in such a way that
> they only take effect if the underlying hardware can support it, but
> don't interfere with correct and efficient operation otherwise.
> 
> For shadow call stack support, which is always supported by the
> hardware, it means it will be enabled even if pointer authentication is
> also supported, and enabled for signing return addresses stored on the
> stack. The additional security provided by shadow call stack is only
> marginal in this case, whereas the performance overhead is not.
> 
> Given that return address signing is based on PACIASP/AUTIASP
> instructions that implicitly operate on the return address register
> (X30) and are not idempotent (i.e., each needs to be emitted exactly
> once before the return address is stored on the ordinary stack and after
> it has been retrieved from it), we can convert these instruction 1:1
> into shadow call stack pushes and pops involving the register X30.
> As this is something that can be done at runtime rather than build time,
> we can do this conditionally based on whether or not return address
> signing is supported on the underlying hardware.
> 
> In order to allow runtimes to unwind call stacks that involve return
> address signing, we track whether or not the return address is currently
> signed by means of DWARF CFI directives in the unwinding metadata. This
> means we can use this information to locate all PACIASP/AUTIASP
> instructions in the binary, instead of having to use brute force and go
> over all instructions in the entire program.
> 
> This series implements this approach for Clang, which has been vetted
> (and fixed in release 15) to ensure that the unwind metadata is 100%
> accurate when it comes to PACIASP/AUTIASP occurrences. Sadly, GCC does
> not always get that quite right, so this series is Clang-only for the
> moment.

Will, Catalin, what's left for this series? I'd really to get this
landed -- it's reviewed and tested, and will be used on real devices.

Thanks!

-Kees

-- 
Kees Cook