linux-kernel - Re: [PATCH v1 03/20] iommu/arm-smmu-v3: Implement arm_smmu_domain_test

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

Message-ID: <aQBopHFub8wyQh5C@Asurada-Nvidia>
Date: Mon, 27 Oct 2025 23:54:28 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: <joro@...tes.org>, <kevin.tian@...el.com>,
	<suravee.suthikulpanit@....com>, <will@...nel.org>, <robin.murphy@....com>,
	<sven@...nel.org>, <j@...nau.net>, <jean-philippe@...aro.org>,
	<robin.clark@....qualcomm.com>, <dwmw2@...radead.org>,
	<baolu.lu@...ux.intel.com>, <yong.wu@...iatek.com>, <matthias.bgg@...il.com>,
	<angelogioacchino.delregno@...labora.com>, <tjeznach@...osinc.com>,
	<pjw@...nel.org>, <palmer@...belt.com>, <aou@...s.berkeley.edu>,
	<heiko@...ech.de>, <schnelle@...ux.ibm.com>, <mjrosato@...ux.ibm.com>,
	<wens@...e.org>, <jernej.skrabec@...il.com>, <samuel@...lland.org>,
	<thierry.reding@...il.com>, <jonathanh@...dia.com>, <iommu@...ts.linux.dev>,
	<linux-kernel@...r.kernel.org>, <asahi@...ts.linux.dev>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-arm-msm@...r.kernel.org>,
	<linux-mediatek@...ts.infradead.org>, <linux-riscv@...ts.infradead.org>,
	<linux-rockchip@...ts.infradead.org>, <linux-s390@...r.kernel.org>,
	<linux-sunxi@...ts.linux.dev>, <linux-tegra@...r.kernel.org>,
	<virtualization@...ts.linux.dev>, <patches@...ts.linux.dev>
Subject: Re: [PATCH v1 03/20] iommu/arm-smmu-v3: Implement
 arm_smmu_domain_test_dev

On Mon, Oct 27, 2025 at 08:26:40PM -0300, Jason Gunthorpe wrote:
> On Mon, Oct 20, 2025 at 01:08:16PM -0700, Nicolin Chen wrote:
> 
> > > I don't see any reasonable way to mitigate this??
> > 
> > Right. It can't simply go through a regular attach_dev call since
> > driver wouldn't expect any inconsistency in the core.
> > 
> > Driver would have to be aware of the reset state, and make a copy
> > of the old domain's CD/STE to use for a test_dev() during a reset.
> 
> It seems convoluted :\

Yea. Both core and driver would end up with complexities Orz.

> IDK if you want to do that some kind of "attach but really don't" flag
> so all the tracking was kept, just the STE was forced to blocking.
> 
> Then since all the fake attaches are tracked and validated switching
> to a real ste shouldn't fail.
> 
> For instance SMMU could continue to build the CD table and act like
> the CD is active, but the STE wouldn't point to it.
> 
> Basically, this approach doesn't seem to solve all the problems, it
> reduces them sure, but there are still enough gaps.

Yea, this works for reset because the physical STE is on an ABORT
state, so SW can concurrently mutate the CD as much as it wants.
Yet, with a translating STE, CD table can't be mutated I suppose?

So this "attach but really don't" flag would be used by the reset
case exclusively. It feels like the surgical in-driver approach
that we thought about in the beginning v.s. the core-managed one
that we wished for to fix all drivers.

By doing so, I think the core could simply forward the two reset
callbacks to the driver where it does an STE-level suspend/resume
and raises a reset flag so that any concurrent attach_dev would
bypass the last STE updates until the reset_done is finished.

This, however, will require driver to implement those callbacks
individually, if it cares to fix the vulnerability..

> So I think we either have to live with them and call it a user bug to
> change the domain improperly during FLR.. If it happens dump the
> translation into blocking and move on..

But, we previously discussed that it'd not be a user bug for VFs,
unless they are all getting reset by the PCI core?

Otherwise, returning -EBUSY rejecting concurrent attach would be
the easiest way.

Thanks
Nicolin