linux-kernel - Re: [PATCH v1 00/20] iommu: Introduce and roll out 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: <20251020162413.GV316284@nvidia.com>
Date: Mon, 20 Oct 2025 13:24:13 -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 00/20] iommu: Introduce and roll out test_dev domain op

On Sun, Oct 12, 2025 at 05:04:57PM -0700, Nicolin Chen wrote:
> Add a new test_dev domain op for drivers to run a compatibility test prior
> to the actual attachment at the driver level. Any incompatible attachment
> will be rejected early, allowing the iommu core to postpone any concurrent
> attachment during a device reset state.

I had to go back and find the original email from kevin to understand
this..

This is a preparatory series for new iommu_dev_reset APIs:
https://lore.kernel.org/all/cover.1756682135.git.nicolinc@nvidia.com/

That series parks the domain attachment at BLOCKED during a device
reset. To keep the uAPI this also required that any change in domain
during this reset sequence is just recorded and kept in the background
until the reset is finished.

This creates a weird hole where userspace could propose to attach to a
domain that is incompatible with the device during FLR, have that
attach queued and then ultimately have the domain attach fail when the
FLR concludes.

This can be mitigated by splitting out the compatability test from the
attach and having the core code check the compatability before
accepting a queued domain attach.

It was felt that the subtle uAPI change warrants this rework.

Jason