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

From: Kees Cook <keescook@chromium.org>
To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Ard Biesheuvel <ardb@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mark Brown <broonie@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH v5 0/3] arm64: dynamic shadow call stack support
Date: Wed, 7 Sep 2022 10:25:41 -0700	[thread overview]
Message-ID: <202209071024.31CBA83C4@keescook> (raw)
In-Reply-To: <20220822095058.2912704-1-ardb@kernel.org>

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

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