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

[Will Deacon <will@kernel.org>]

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.

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. If it *does*, then I can see the argument for
treating this like an erratum, but then we should zap CSV3 and treat
these parts as being affected by meltdown. On the other hand, if CSV3
is not intended to cover these prefetchers, then we probably need to
add a new "CVE-2024-7881" entry to /sys/devices/system/cpu/vulnerabilities.

As it stands with this patch series, userspace has no way to know about
the problem. kpti gets silently enabled in dmesg:

  | CPU features: detected: Kernel page table isolation (KPTI)

but the contents of the vulnerabilities directory is pretty misleading:

  gather_data_sampling: Not affected
  ghostwrite: Not affected
  itlb_multihit: Not affected
  l1tf: Not affected
  mds: Not affected
  meltdown: Not affected
  mmio_stale_data: Not affected
  reg_file_data_sampling: Not affected
  retbleed: Not affected
  spec_rstack_overflow: Not affected
  spec_store_bypass: Mitigation: Speculative Store Bypass disabled via prctl
  spectre_v1: Mitigation: __user pointer sanitization
  spectre_v2: Mitigation: CSV2, BHB
  srbds: Not affected
  tsx_async_abort: Not affected

The meltdown entry doesn't even mention that KPTI has been enabled.

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.

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.

Will