Re: [PATCH 0/4] arm64: mitigate CVE-2024-7881 in the absence of firmware mitigation

[Oliver Upton <oliver.upton@linux.dev>]

On Mon, Mar 17, 2025 at 09:26:12PM +0000, Will Deacon wrote:
> On Fri, Mar 14, 2025 at 06:37:25PM +0000, Catalin Marinas wrote:
> > On Tue, 28 Jan 2025 15:54:24 +0000, Mark Rutland wrote:
> > > On some CPUs from Arm Ltd, it is possible for unprivileged code to cause
> > > a hardware prefetcher to form an address using the contents of a memory
> > > location which is accessible by privileged accesses in the active
> > > translation regime, potentially leaking the contents of this memory
> > > location via a side channel. This has been assigned CVE-2024-7881:
> > > 
> > >   https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881
> > > 
> > > [...]
> > 
> > Applied to arm64 (for-next/leaky-prefetcher), thanks!
> > 
> > There hasn't been much review (thanks Oliver for looking at the KVM
> > bits) and there's some implied work that can go on top of this series.
> > But the patches looked fine to me, so I queued them. Mark or others,
> > please shout if you'd like them dropped, they are on a branch.
> 
> I'm really not comfortable with this series and would prefer to see it
> dropped while we continue the discussion, especially as it's causing
> minor conflicts with the KVM/arm64 tree in -next.

Catalin, unless you say otherwise, I'm going to assume this will be
dropped in the interim.

> The series is pitched a bit like an erratum workaround, but the overall
> problem that a memory-dependent prefetcher can bypass permission checks
> is fairly general and, even if nobody else gets this wrong, I doubt that
> it's the last time Arm will mess it up. So, while the EL3 mitigation may
> be Arm-specific, I don't think the rest of it really is. That's
> especially true given the sorry state of spectre mitigations on
> third-party derivatives of Arm designs, such as the Qualcomm Kryo parts,
> and the fact that we provide userspace with a mechanism today for
> querying the state of those mitigations via sysfs.
> 
> The immediate question, then, is whether this broken behaviour is
> prohibited by CSV3. The text in the latest Arm ARM just refers to
> "Data loaded under speculation", so it's not entirely clear whether that
> applies to a prefetcher.

Hmm, good point. I think prefetchers fall under the ARM ARM glossary
definition of speculation, which includes:

 - Operations generated by the hardware that are not directly generated
   by any instructions appearing in the Execution stream.

> If we decide to go with a new entry for this, then we also need to
> change the default behaviour along the lines of Doug's Spectre-BHB
> changes queued on for-next/spectre-bhb-assume-vulnerable so that we
> assume vulnerable if we don't know better. To do otherwise will result
> in false assurances to userspace on derivative and third-party
> implementations.

Is the idea here that we'd assume any part with FEAT_CSV3 is vulnerable
to CVE-2024-7881 unless told otherwise by firmware / known good list of
implementations?

ARCH_WORKAROUND_4 assumes software has already detected an affected
implementation and doesn't distinguish between "not affected" and "not
mitigated". So I'd be concerned that we're gonna turn on KPTI for a load
of unrelated parts for something that hasn't (yet) been defined as a new
ecosystem bug.

> To be clear: I'm not at all against mitigating this problem and
> advertising the status of that mitigation. I *am* against quietly
> handling it like a CPU erratum whilst simultaneously telling userspace
> that meltdown is not a problem regardless of the mitigation state.

I like your idea of treating this as a broken CSV3 implementation
instead of an entirely new CPU bug, if only to avoid the 'assume the
worst' problem.

Either way KVM will need to implement the SMCCC call to the letter, even
if we wind up nuking CSV3.

Thanks,
Oliver