[PATCH 0/6] arm64: errata: Disable FWB on parts with non-ARM interconnects

[Will Deacon]

Hi James,

On Thu, Mar 30, 2023 at 05:51:22PM +0100, James Morse wrote:
> Changes since the RFC?:
>  * Added DT support, in a way that means we don't end up with per-erratum
>    strings, or bloat in the calling code to check for those strings.
>  * Added a commandline argument. (boo)
>  * Changes to support errata affecting features on big-little systems properly.
> 
> ~
> 
> When stage1 translation is disabled, the SCTRL_E1.I bit controls the
> attributes used for instruction fetch, one of the options results in a
> non-cacheable access. A whole host of CPUs missed the FWB override
> in this case, meaning a KVM guest could fetch stale/junk data instead of
> instructions.
> 
> The workaround is to disable FWB, and do the required cache maintenance
> instead.
> 
> The good news is, this isn't a problem for systems using Arm's
> interconnect IP. The bad news is: linux can't know this. Arm knows of
> at least one platform that is affected by this erratum.
> 
> 
> This series adds support for the 'Errata Management Firmware Interface', [0]
> and queries that to determine if the CPU is affected or not. DT support is
> added so that the firmware interface values can be queried directly from the
> DT. This can be used as a fallback for platforms that don't yet support the
> interface.

It occurs to me that, when a device is assigned to a VM, there are a
whole bunch of non-probeable reasons why FWB cannot be used and perhaps
we should be looking to advertise that from firmware without pulling in
a reliance on this errata management interface.

Right now, I don't think KVM or VFIO do anything to prevent the assignment
of a device capable of non-coherent DMA traffic and FWB is used if the CPUs
support it. This, in theory, allows the guest to read stale data from host
memory pages using non-coherent DMA and I think we should gate usage of FWB
for a given VM on whether or not that VM has such a device assigned.

The problem is that I don't think you can probe this property reliably. It's
not enough to check for "dma-coherent"; rather we also need to know details
about the IOMMU and device-specific properties such as the ability to
generate NoSnoop transactions. I think firmware is probably the only option
here, so since you're proposing something similar, please can we make it
general enough to be used outside of errata scenarios?

Will