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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aW9xs1ko3nWq5VbS@willie-the-truck>
Date: Tue, 20 Jan 2026 12:14:43 +0000
From: Will Deacon <will@...nel.org>
To: Jason Gunthorpe <jgg@...pe.ca>
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 Mon, Jan 05, 2026 at 02:54:23PM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 05, 2026 at 04:02:34PM +0000, Robin Murphy wrote:
> 
> > > It is reasonable that Linux will set the attributes properly based on
> > > what it is doing. Setting the wrong attributes and expecting the HW to
> > > ignore them seems like a hacky direction.
> > 
> > Oh, I'm not saying that we *shouldn't* set our attributes more exactly -
> > this would still be needed for doing things the "right" way too - I just
> > want to be very clear on the reasons why. 
> 
> At least I know of HW where the SMMU fetches covered by COHACC:
> 
>  * Translation table walks.
>  * Fetches of L1STD, STE, L1CD and CD.
>  * Command queue, Event queue and PRI queue access.
>  * GERROR, CMD_SYNC, Event queue and PRI queue MSIs, if supported.
> 
> Have a mixture of coherency support. The SOC has multiple fabrics, one
> non-coherent one specifically for isochronous traffic.  In HW some
> SMMU sub-units (like the table walk) been wired to the isochronous
> fabric, while others are using the normal coherent fabric.
> 
> So when it comes to this statement:
> 
>  If either the SMMU or system cannot *fully* support IO-coherent
>  access to SMMU structures/queues/translations, this reads as 0.
> 
> The HW is "partially" IO-coherent, so COHACC is 0.
> 
> It has been lucky that so far the incorrect attributes haven't caused a
> problem, but the next spin of this HW may have issue here. I'd like to
> see it fixed.

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. 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.

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.

Will