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

Message-ID: <20251027232640.GE1018328@nvidia.com>
Date: Mon, 27 Oct 2025 20:26:40 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...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 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 :\

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.

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

Or we have to do some kind of fake attach tracking which doesn't sound
appealing..

Jason