linux-kernel - Re: [PATCH v2] arm64: errata: Workaround for SI L1 downstream coherency issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260108161310.GE23056@nvidia.com>
Date: Thu, 8 Jan 2026 12:13:10 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Will Deacon <will@...nel.org>
Cc: Robin Murphy <robin.murphy@....com>, Marc Zyngier <maz@...nel.org>,
	Lucas Wei <lucaswei@...gle.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Jonathan Corbet <corbet@....net>, sjadavani@...gle.com,
	kernel test robot <lkp@...el.com>, stable@...r.kernel.org,
	kernel-team@...roid.com, linux-arm-kernel@...ts.infradead.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	smostafa@...gle.com
Subject: Re: [PATCH v2] arm64: errata: Workaround for SI L1 downstream
 coherency issue

On Thu, Jan 08, 2026 at 03:18:02PM +0000, Will Deacon wrote:
> I think IOMMU_CAP_CACHE_COHERENCY is supposed to indicate whether or not
> the endpoint devices are coherent (i.e. whether IOMMU_CACHE makes
> sense)

Yes, that's broadly right.

VFIO/iommufd does not do any cache flushing for their own mappings, so
if the guest can use DMA to cause cache incoherence for those mappings
nothing will clean it up and you get the general problems that come
with that.

Broadly IOMMU_CACHE (which IOMMU_CAP_CACHE_COHERENCY says works), in
common non-hostile cases, prevents incoherence.

Since it is not complete against hostile guests, we also have
IOMMU_CAP_ENFORCE_CACHE_COHERENCY which is supposed to mean that if
VFIO sets IOMMU_CACHE then there is no way for the VM to bypass the
cache with DMA (including PCI no-snoop TLPs, incomming attributes and
so on).

There ARM story here is not great, but with admin care you can create VMs
that are safe, and CANWBS server HW is just completely safe. Like has
been said in this thread Linux just can't tell the safe/unsafe cases
apart in ARM land, so we are punting this on the admin to deal with.

eg a PCI device that never issues a no-snoop TLP is safe under weaker
IOMMU_CAP_CACHE_COHERENCY HW, but some integrated GPU masquerading as
a PCIe device is probably not.

> but it's true that, for the SMMU, we tie this to the coherency of the
> SMMU itself so it is a bit sketchy. There's an interesting thread between
> Mostafa and Jason about it:

I've tried a few times to inject the ACPI per-PCI device coherency
flags into the logic and failed every time ..

The stated purpose of VFIO is to not allow incoherent devices in VFIO,
so if an admin manages to do this through one of the holes we
don't/can't check then it is admin error :(

> But, that aside, FWB throws a pretty big spanner in the works if we want
> to assign non-coherent devices.

Yes, at least guest operating under FWB wouldn't have a working
dma_alloc_coherent() so the VM would be pretty broken. No VMM can set
the ACPI/DT to mark devices as non-coherent in the VM for this
reason..

I gather Mostafa is trying to make pkvm support non-coherent devices,
I assume he is giving up FWB and stuff as well to make it work.

Jason