linux-kernel - Re: [RFC PATCH v2 00/32] Add live update state preservation

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: <20260128195943.GY1641016@ziepe.ca>
Date: Wed, 28 Jan 2026 15:59:43 -0400
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>,
	Alex Williamson <alex@...zbot.org>, 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,
	YiFei Zhu <zhuyifei@...gle.com>, Chris Li <chrisl@...nel.org>,
	praan@...gle.com
Subject: Re: [RFC PATCH v2 00/32] Add live update state preservation

On Tue, Dec 02, 2025 at 11:02:30PM +0000, Samiullah Khawaja wrote:
> 
> Samiullah Khawaja (26):
>   iommu: Add liveupdate FLB for IOMMU state preservation
>   iommu: Register IOMMU FLB with iommufd file handler
>   iommu: Implement IOMMU LU FLB preserve/unpreserve callbacks
>   iommu: Add iommu_domain ops to preserve, unpreserve and restore
>   iommu/pages: Add APIs to preserve/unpreserve/restore iommu pages
>   iommupt: Implement preserve/unpreserve/restore callbacks
>   iommu: Add APIs to preserve/unpreserve iommu domains
>   iommufd: Use the iommu_domain_preserve/unpreserve APIs
>   iommu: Add API to keep track of iommu domain attachments
>   iommu: Add API to preserve/unpreserve a device
>   iommu/vt-d: Implement device and iommu preserve/unpreserve ops
>   iommufd: Add APIs to preserve/unpreserve a vfio cdev
>   vfio/pci: Preserve the iommufd state of the vfio cdev
>   iommu: Add APIs to get preserved state of a device
>   iommu/vt-d: Clean the context entries of unpreserved devices
>   iommu: Implement IOMMU FLB retrieve and finish ops
>   iommu: Add an API get the preserved state of an IOMMU
>   iommu/vt-d: restore state of the preserved IOMMU
>   iommu: Add helper APIs to fetch preserved device state
>   iommu/vt-d: reclaim domain ids of the preserved devices
>   iommu: restore preserved domain and reattach
>   iommu/vt-d: reuse the preserved domain id for preserved devices
>   iommufd: Handle the iommufd can_finish properly
>   iommu: Transfer device ownership after liveupdate
>   iommu: Allow replacing restored domain
>   iommufd/selftest: Add test to verify iommufd preservation
> 
> YiFei Zhu (6):
>   iommufd: Allow HWPTs to have a NULL IOAS
>   iommufd: split alloc and domain assign from iommufd_hwpt_paging_alloc
>   iommufd: Add basic skeleton based on liveupdate_file_handler
>   iommufd-lu: Implement basic prepare/cancel/finish/retrieve using
>     folios
>   iommufd-lu: Implement ioctl to let userspace mark an HWPT to be
>     preserved
>   iommufd-lu: Persist iommu hardware pagetables for live update

This really needs to be made smaller and more focused to be
reviewable and mergable. Try to stick to 15-ish patches.

There is a lot giong on here, I suggest focusing this only on the main
iommu core, a vt-d driver implementation of the bare minimum, and an
iommufd function to trigger preservation of a domain.

Start off by just making the successor kernel fail to accept any
drivers at all because the iommu_domain was preserved. ie restore the
domain and set it as the default_domain and then fail in
iommu_device_use_default_domain() and related functions.

All it should do is convey an iommu_domain and the pasid table entry
unchanged without hit from prior to successor kernel. That's the bare
minimum.

Then a second series which picks up from there and feeds the sucessor path
through iommufd/vfio.

Jason