linux-kernel - Re: [PATCH] iommu/arm-smmu-v3: Maintain valid access attributes for non-coherent SMMU

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20260120131150.GM961572@ziepe.ca>
Date: Tue, 20 Jan 2026 09:11:50 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: Will Deacon <will@...nel.org>
Cc: Robin Murphy <robin.murphy@....com>, Dawei Li <dawei.li@...ux.dev>,
	joro@...tes.org, linux-arm-kernel@...ts.infradead.org,
	iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
	set_pte_at@...look.com, stable@...r.kernel.org
Subject: Re: [PATCH] iommu/arm-smmu-v3: Maintain valid access attributes for
 non-coherent SMMU

On Tue, Jan 20, 2026 at 12:14:43PM +0000, Will Deacon wrote:
> I'm not against being more careful about the memory attributes used by
> the non-coherent walker, but we shouldn't fool ourselves into thinking
> that Linux can treat coherent devices as non-coherent and expect things
> to work generally. 

Probably not generally, but we will need much more flexible
coherent/non-coherent choices for some upcoming HW that cannot support
cachable access for certain isochronous DMA flows.

The device driver will know this, and it will know the underlying HW
works properly, so it can safely opt in without worrying about
"generally".

PCIe defined no-snoop TLPs a long time ago for these isochronous cases
and we haven't done a great job supporting this feature in Linux so far.

> The use of non-cacheable mappings in
> dma_alloc_coherent() and cache invalidation in the streaming API when
> transferring buffer ownership back to the CPU can both lead to DMA
> corruption if the device can snoop the CPU caches.

That's a bit different situation, here we are talking about the SMMU
itself and things like the page table walker are fine if the HW does
cachable or non-cachable because we can flush the caches and the HW
never writes. The same argument works for the stream table and CD
tables, but they'd have to switch away from dma_alloc_coherent().

Certainly the end device driver doing DMA can't get off so easy, but
it is also not so unreasonable to think that the driver should know
that the SOC block it is driving has an appropriate HW implementation
for no-snoop.

> I think we're all agreed on that, but just wanted to make sure as this
> is something that has come up before when talking to hardware folks
> who seem to think that the "dma-coherent" property is a hint.

What I've been pushing for is that the SMMU architected cache
properties have to be followed. If the architecture says the
transaction must be cachable then the HW must actually cache snoop it.

However, this goes the other way too and if the architecture says the
transaction should be uncached the HW can bypass the cache.

Hence my interest in this series because HW that follows the
architected cache properties is going to be sad if Linux doesn't set
them right.

If the HW actually implements the cache properties then the SW needs
to select cached/non-cached on a (sub)stream basis to support
isochronous flows. If the SW doesn't do this and just selects the
deafult cachable then the DMAs will work and transfer the right data,
but the realtime guarantees will fail and other parts of the system
will have errors.

Jason