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

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

On Fri, Jan 31, 2025 at 11:01:38AM +0000, Mark Rutland wrote:
> On Thu, Jan 30, 2025 at 01:48:53PM -0800, Oliver Upton wrote:
> > Hi Mark,
> > 
> > On Tue, Jan 28, 2025 at 03:54:24PM +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
> > > 
> > > Arm's recommended mitigation is that firmware configures an
> > > IMPLEMENTATION DEFINED control bit (CPUACTLR6_EL1[41]) to disable the
> > > affected prefetcher, and updates to Trusted Firmware-A are available to
> > > do this. For systems which have not yet recevied a firmware update, KPTI
> > > can help to mitigate the issue.
> > > 
> > > These patches enable KPTI for affected parts when the firmware
> > > mitigation is not present. The presence of the mitigation is identified
> > > by the presence of the SMCCC_ARCH_WORKAROUND_4 SMCCC call, which was
> > > deployed with the mitigation. This is documented in the SMCCC 1.6 G BET0
> > > specification:
> > > 
> > >   https://developer.arm.com/documentation/den0028/gbet0/?lang=en
> > > 
> > > I have tested this on a few configurations of virtual platforms. I'd
> > > appreciate any feedback, especially on the KVM changes.
> > 
> > The KVM changes look reasonable and follow the usual model for this
> > crud. It would be nice to report the mitigation state to userspace
> > somehow as I would like to have a KVM selftest for all of the hardware
> > vulnerabilities.
> 
> Lemme go figure that out. Just to check, do you mean exposed through a
> KVM mechanism, or under /sys/devices/system/cpu/vulnerabilities/ ? I
> assume the latter.

Yep, the latter. Google has a test out of tree that checks the pseudo-FW
registers, hypercalls, and guest ID registers against what's in sysfs.

-- 
Thanks,
Oliver