Re: [PATCH] KVM: arm64: Prevent vcpu_has_ptrauth from generating OOL functions

From: Nathan Chancellor <natechancellor@gmail.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org,
	James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Will Deacon <will@kernel.org>,
	kernel-team@android.com,
	Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH] KVM: arm64: Prevent vcpu_has_ptrauth from generating OOL functions
Date: Wed, 22 Jul 2020 19:51:42 -0700	[thread overview]
Message-ID: <20200723025142.GA361584@ubuntu-n2-xlarge-x86> (raw)
In-Reply-To: <20200722162231.3689767-1-maz@kernel.org>

On Wed, Jul 22, 2020 at 05:22:31PM +0100, Marc Zyngier wrote:
> So far, vcpu_has_ptrauth() is implemented in terms of system_supports_*_auth()
> calls, which are declared "inline". In some specific conditions (clang
> and SCS), the "inline" very much turns into an "out of line", which
> leads to a fireworks when this predicate is evaluated on a non-VHE
> system (right at the beginning of __hyp_handle_ptrauth).
> 
> Instead, make sure vcpu_has_ptrauth gets expanded inline by directly
> using the cpus_have_final_cap() helpers, which are __always_inline,
> generate much better code, and are the only thing that make sense when
> running at EL2 on a nVHE system.
> 
> Fixes: 29eb5a3c57f7 ("KVM: arm64: Handle PtrAuth traps early")
> Reported-by: Nathan Chancellor <natechancellor@gmail.com>
> Reported-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>

Thank you for the quick fix! I have booted a mainline kernel with this
patch with Shadow Call Stack enabled and verified that using KVM no
longer causes a panic.

Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>

For the future, is there an easy way to tell which type of system I am
using (nVHE or VHE)? I am new to the arm64 KVM world but it is something
that I am going to continue to test with various clang technologies now
that I have actual hardware capable of it that can run a mainline
kernel.

Cheers,
Nathan

> ---
>  arch/arm64/include/asm/kvm_host.h | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 147064314abf..a8278f6873e6 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -391,9 +391,14 @@ struct kvm_vcpu_arch {
>  #define vcpu_has_sve(vcpu) (system_supports_sve() && \
>  			    ((vcpu)->arch.flags & KVM_ARM64_GUEST_HAS_SVE))
>  
> -#define vcpu_has_ptrauth(vcpu)	((system_supports_address_auth() || \
> -				  system_supports_generic_auth()) && \
> -				 ((vcpu)->arch.flags & KVM_ARM64_GUEST_HAS_PTRAUTH))
> +#ifdef CONFIG_ARM64_PTR_AUTH
> +#define vcpu_has_ptrauth(vcpu)						\
> +	((cpus_have_final_cap(ARM64_HAS_ADDRESS_AUTH) ||		\
> +	  cpus_have_final_cap(ARM64_HAS_GENERIC_AUTH)) &&		\
> +	 (vcpu)->arch.flags & KVM_ARM64_GUEST_HAS_PTRAUTH)
> +#else
> +#define vcpu_has_ptrauth(vcpu)		false
> +#endif
>  
>  #define vcpu_gp_regs(v)		(&(v)->arch.ctxt.gp_regs)
>  
> -- 
> 2.28.0.rc0.142.g3c755180ce-goog
> 