linux-kernel - Re: [RFC PATCH 05/15] iommu: Introduce API to preserve iommu domain

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: <20250929155430.GD2695987@ziepe.ca>
Date: Mon, 29 Sep 2025 12:54:30 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Samiullah Khawaja <skhawaja@...gle.com>
Cc: David Woodhouse <dwmw2@...radead.org>,
	Lu Baolu <baolu.lu@...ux.intel.com>, Joerg Roedel <joro@...tes.org>,
	Will Deacon <will@...nel.org>,
	Pasha Tatashin <pasha.tatashin@...een.com>, iommu@...ts.linux.dev,
	Robin Murphy <robin.murphy@....com>,
	Pratyush Yadav <pratyush@...nel.org>,
	Kevin Tian <kevin.tian@...el.com>, linux-kernel@...r.kernel.org,
	Saeed Mahameed <saeedm@...dia.com>,
	Adithya Jayachandran <ajayachandra@...dia.com>,
	Parav Pandit <parav@...dia.com>,
	Leon Romanovsky <leonro@...dia.com>, William Tu <witu@...dia.com>,
	Vipin Sharma <vipinsh@...gle.com>, dmatlack@...gle.com,
	zhuyifei@...gle.com, Chris Li <chrisl@...nel.org>, praan@...gle.com
Subject: Re: [RFC PATCH 05/15] iommu: Introduce API to preserve iommu domain

On Sun, Sep 28, 2025 at 07:06:13PM +0000, Samiullah Khawaja wrote:
> Add an API that can be called by the iommu users to preserve iommu
> domain. Currently it only marks the iommu_domain as preserved.

Merge it with the previous path

> +#ifdef CONFIG_LIVEUPDATE
> +	atomic_set(&domain->preserved, 0);
> +#endif

The memory is kzallocated, I don't think this is needed

> +int iommu_domain_preserve(struct iommu_domain *domain)
> +{

I expect this to accept some kind of luo pointer to signal what stream
the domain is part of.

Domains are linked to iommufd's which are linked to luo sessions. This
all needs to be carefully conveyed down to all the lower levels.

I also expect preserve to return some kind of handle that the caller
can hide away to deserialize.

> +	lockdep_assert_held(&liveupdate_state_rwsem);
> +	if (!domain->ops->preserve)
> +		return -EOPNOTSUPP;
> +
> +	ret = domain->ops->preserve(domain);
> +	if (!ret)
> +		atomic_set(&domain->preserved, 1);

And if we have a caller handle then there is probably no reason to
have this state tracking atomic.

Jason