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

[Mark Rutland <mark.rutland@arm.com>]

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.

> But anyway,
> 
> Reviewed-by: Oliver Upton <oliver.upton@linux.dev>

Thanks; much appreciated!

Mark.