linux-kernel - Re: [PATCH] KVM: arm64: Check cpu_has_spe() before initializing PMSCR

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aOasxgCMG0yS4t43@linux.dev>
Date: Wed, 8 Oct 2025 11:26:14 -0700
From: Oliver Upton <oliver.upton@...ux.dev>
To: Marc Zyngier <maz@...nel.org>
Cc: Mukesh Ojha <mukesh.ojha@....qualcomm.com>, joey.gouly@....com,
	suzuki.poulose@....com, yuzenghui@...wei.com,
	catalin.marinas@....com, will@...nel.org, alexandru.elisei@....com,
	linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: arm64: Check cpu_has_spe() before initializing
 PMSCR_EL1 in VHE

On Wed, Oct 08, 2025 at 11:46:55AM +0100, Marc Zyngier wrote:
> On Tue, 07 Oct 2025 19:31:45 +0100,
> Oliver Upton <oliver.upton@...ux.dev> wrote:
> > 
> > Hi Mukesh,
> > 
> > I find it a bit odd to refer to cpu_has_spe() in the shortlog, which
> > doesn't exist prior to this patch.
> > 
> > On Tue, Oct 07, 2025 at 11:53:56PM +0530, Mukesh Ojha wrote:
> > > commit efad60e46057 ("KVM: arm64: Initialize PMSCR_EL1 when in VHE")
> > > initializes PMSCR_EL1 to 0 which is making the boot up stuck when KVM
> > > runs in VHE mode and reverting the change is fixing the issue.
> > > 
> > > [    2.967447] RPC: Registered tcp NFSv4.1 backchannel transport module.
> > > [    2.974061] PCI: CLS 0 bytes, default 64
> > > [    2.978171] Unpacking initramfs...
> > > [    2.982889] kvm [1]: nv: 568 coarse grained trap handlers
> > > [    2.988573] kvm [1]: IPA Size Limit: 40 bits
> > > 
> > > Lets guard the change with cpu_has_spe() check so that it only affects
> > > the cpu which has SPE feature supported.
> > 
> > This could benefit from being spelled out a bit more. In both cases we
> > check for the presence of FEAT_SPE, however I believe the issue you
> > observe is EL3 hasn't delegated ownership of the Profiling Buffer to
> > Non-secure nor does it reinject an UNDEF in response to the sysreg trap.
> > 
> > I agree that the change is correct but the rationale needs to be clear.
> 
> To me, this smells a lot more like some sort of papering over a
> firmware bug. Why isn't SPE available the first place?

While I agree this points the finger at a half-assed EL3, the
architecture explicitly allows this sort of crap and we cope with the
accessibility of SPE in almost every other case.

We should at least be consistent in how we handle an inaccessible SPE.

Thanks,
Oliver