linux-kernel - Re: [PATCH v7] 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <86seoiru3t.wl-maz@kernel.org>
Date: Thu, 13 Feb 2025 10:56:22 +0000
From: Marc Zyngier <maz@...nel.org>
To: Mark Rutland <mark.rutland@....com>
Cc: Mark Brown <broonie@...nel.org>,
	linux-arm-kernel@...ts.infradead.org,
	kvmarm@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	Fuad Tabba <tabba@...gle.com>,
	Oliver Upton <oliver.upton@...ux.dev>,
	James Morse <james.morse@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>
Subject: Re: [PATCH v7] KVM: arm64: Fix confusion in documentation for pKVM SME assert

On Thu, 13 Feb 2025 09:24:22 +0000,
Mark Rutland <mark.rutland@....com> wrote:
> 
> On Thu, Feb 13, 2025 at 08:55:52AM +0000, Marc Zyngier wrote:
> > On Wed, 12 Feb 2025 11:11:04 +0000,
> > Mark Rutland <mark.rutland@....com> wrote:
> > > On Wed, Feb 12, 2025 at 12:44:57AM +0000, Mark Brown wrote:
> > > > diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> > > > index 4d3d1a2eb157047b4b2488e9c4ffaabc6f5a0818..e37e53883c357093ff4455f5afdaec90e662d744 100644
> > > > --- a/arch/arm64/kvm/fpsimd.c
> > > > +++ b/arch/arm64/kvm/fpsimd.c
> > > > @@ -93,11 +93,14 @@ 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.
> > > > +	 * Protected and non-protected KVM modes require that
> > > > +	 * SVCR.{SM,ZA} == {0,0} when entering a guest so that no
> > > > +	 * host/guest SME state needs to be saved/restored by hyp code.
> > > > +	 *
> > > > +	 * In protected mode, hyp code will verify this later.
> > > >  	 */
> > > > -	WARN_ON(is_protected_kvm_enabled() && system_supports_sme() &&
> > > > -		read_sysreg_s(SYS_SVCR));
> > > > +	WARN_ON_ONCE(is_protected_kvm_enabled() && system_supports_sme() &&
> > > > +		     read_sysreg_s(SYS_SVCR));
> > > 
> > > As I mentioned on the last round, we can drop the is_protected_kvm_enabled()
> > > check, i.e. have:
> > > 
> > > 	/*
> > > 	 * Protected and non-protected KVM modes require that
> > > 	 * SVCR.{SM,ZA} == {0,0} when entering a guest so that no
> > > 	 * host/guest SME state needs to be saved/restored by hyp code.
> > > 	 *
> > > 	 * In protected mode, hyp code will verify this later.
> > > 	 */
> > > 	WARN_ON_ONCE(system_supports_sme() && read_sysreg_s(SYS_SVCR));
> > > 
> > > Either way:
> > > 
> > > Acked-by: Mark Rutland <mark.rutland@....com>
> > > 
> > > Marc, are you happy to queue this atop the recent fixes from me? Those
> > > try to ensure SVCR.{SM,ZA} == {0,0} regardless of whether KVM is in
> > > protected mode.
> > 
> > In all honesty, I find that at this stage, the comment just gets in
> > the way and is over-describing what is at stake here.
> > 
> > The
> > 
> >  	WARN_ON_ONCE(system_supports_sme() && read_sysreg_s(SYS_SVCR));
> > 
> > is really the only thing that matters. It perfectly shows what we are
> > checking for, and doesn't need an exegesis.
> > 
> > As for the Fixes: tag, and given the magnitude of the actual fixes
> > that are already queued, I don't think we need it.
> 
> That's fair; if you haven't spun a patch for that already, I guess we're
> after the following?

Yup. Applied to fixes.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.