linux-kernel - Re: [PATCH] KVM: arm64: Fix confusion in documentation for pKVM SME assert

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 4 Jun 2024 12:17:41 -0700
From: Oliver Upton <oliver.upton@...ux.dev>
To: Mark Brown <broonie@...nel.org>
Cc: Marc Zyngier <maz@...nel.org>, James Morse <james.morse@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Fuad Tabba <tabba@...gle.com>,
	linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: arm64: Fix confusion in documentation for pKVM SME
 assert

Hi,

On Tue, Jun 04, 2024 at 07:47:01PM +0100, Mark Brown wrote:
> As raised in the review comments for the original patch the assert and
> comment added in afb91f5f8ad7 ("KVM: arm64: Ensure that SME controls are
> disabled in protected mode") are bogus. The comments says that we check
> that we do not have SME enabled for a pKVM guest but the assert actually
> checks to see if the host has anything set in SVCR which is unrelated to
> the guest features or state, regardless of if those guests are protected
> or not.
> 
> What I believe the check is actually intended to validate is that we do
> not enter the pKVM hypervisor with SME enabled since the pKVM hypervisor
> does not yet understand SME and is therefore unable to save or restore
> host state with SME enabled, indeed attempting to save SVE state would
> fault if streaming mode is enabled on a system without FA64 due to FFR.
> Update the comment to reflect this.

The added context likely isn't necessary in what winds up getting
applied. Can this just directly state the WARN_ON() exists b/c the
protected mode hypervisor doesn't know how to manage SME state?

> Fixes: afb91f5f8ad7 ("KVM: arm64: Ensure that SME controls are disabled in protected mode")
> Signed-off-by: Mark Brown <broonie@...nel.org>
> ---
>  arch/arm64/kvm/fpsimd.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index 521b32868d0d..f720ba47b85c 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -92,8 +92,9 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
>  	}
>  
>  	/*
> -	 * If normal guests gain SME support, maintain this behavior for pKVM
> -	 * guests, which don't support SME.
> +	 * The pKVM hypervisor does not yet understand how to save or
> +	 * restore SME state for the host so double check that if we
> +	 * are running with pKVM we have disabled SME.
>  	 */
>  	WARN_ON(is_protected_kvm_enabled() && system_supports_sme() &&
>  		read_sysreg_s(SYS_SVCR));

While we're here, this should be WARN_ON_ONCE() or WARN_RATELIMIT() if
we _really_ want some spam. But a single WARN ought to be enough.

It'd be a good idea to also document why we're testing for SME state
twice on the KVM_RUN path, as any WARN() in the hyp code is currently
fatal. I'm guessing Fuad meant to have a non-fatal way of getting some
debug information out.

-- 
Thanks,
Oliver