linux-kernel - Re: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on

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: <aXi5W-7b2odQQtqy@willie-the-truck>
Date: Tue, 27 Jan 2026 13:10:51 +0000
From: Will Deacon <will@...nel.org>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Robin Murphy <robin.murphy@....com>, Nicolin Chen <nicolinc@...dia.com>,
	bhelgaas@...gle.com, joro@...tes.org, praan@...gle.com,
	baolu.lu@...ux.intel.com, kevin.tian@...el.com,
	miko.lenczewski@....com, linux-arm-kernel@...ts.infradead.org,
	iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on

On Mon, Jan 26, 2026 at 03:09:35PM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 26, 2026 at 06:49:07PM +0000, Robin Murphy wrote:
> > (assuming SSIDSIZE > 0 and it does anything at all - note that strictly we
> > cannot assume this bypass trick is *always* possible, since an SMMU is
> > permitted to support ATS without supporting SubStreams).
> 
> Yes, I think Nicolin has captured those conditions in computing
> it... We don't have a logic to disable bypass in that case though.
> 
> > > So, I think a CD table pointer to a fully invalid L1 table of at least
> > > size 1 should be OK?
> > > 
> > > Or stated another way, why would ie be OK to have a 1 level table with
> > > an non-valid CD table entry for SSID0 but not OK to have a 2 level
> > > table that returns non-valid at the first walk?
> > 
> > S1ContextPtr itself is reachable since S1 is enabled, so it cannot point to
> > nonsense. But the S1DSS==Bypass behaviour does state:
> 
> > "Note: Such a transaction does not fetch a CD, and therefore does not report
> > F_CD_FETCH, C_BAD_CD or a stage 2 Translation-related fault with CLASS ==
> > CD."
> 
> Yes
> 
> However, taken together:
>  * S1CDMax is set to substream 0 only
>  * S1DSS is set such that "does not fetch a CD" for SSID = 0
>  * SSID >0 doesn't fetch CDs because of S1CDMax
> 
> Then it seems to be saying that it will never use S1ContextPtr? ie it
> is IGNORED?

Right, I think the critical question is whether that setting of S1DSS
(0b01) means that STE.S1ContextPtr is considered "invalid". The spec
doesn't call this out explicitly but the "translation procedure charts"
seem to indicate that it doesn't use the CD for anything...

It would be good to get some clarification from Arm about this
particular case.

Will