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: <aV_KqiaDf9-2NcxH@willie-the-truck>
Date: Thu, 8 Jan 2026 15:18:02 +0000
From: Will Deacon <will@...nel.org>
To: Robin Murphy <robin.murphy@....com>
Cc: 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, jgg@...dia.com
Subject: Re: [PATCH v2] arm64: errata: Workaround for SI L1 downstream
 coherency issue

On Wed, Jan 07, 2026 at 05:55:40PM +0000, Robin Murphy wrote:
> On 2026-01-07 4:33 pm, Will Deacon wrote:
> > On Thu, Jan 01, 2026 at 06:55:05PM +0000, Marc Zyngier wrote:
> > > The other elephant in the room is virtualisation: how does a guest
> > > performing CMOs deals with this? How does it discover the that the
> > > host is broken? I also don't see any attempt to make KVM handle the
> > > erratum on behalf of the guest...
> > 
> > A guest shouldn't have to worry about the problem, as it only affects
> > clean to PoC for non-coherent DMA agents that reside downstream of the
> > SLC in the interconnect. Since VFIO doesn't permit assigning
> > non-coherent devices to a guest, guests shouldn't ever need to push
> > writes that far (and FWB would cause bigger problems if that was
> > something we wanted to support)
> > 
> > +Mostafa to keep me honest on the VFIO front.
> 
> I don't think we actually prevent non-coherent devices being assigned, we
> just rely on the IOMMU supporting IOMMU_CAP_CACHE_COHERENCY. Thus if there's
> an I/O-coherent SMMU then it could end up being permitted, however I would
> hope that either the affected devices are not behind such an SMMU, or at
> least that if the SMMU imposes cacheable attributes then that prevents
> traffic from taking the back-door path to RAM.

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)
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:

https://lore.kernel.org/all/ZtHhdj6RAKACBCUG@google.com/

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

Will