linux-kernel - RE: [RFC PATCH] iommufd: Destroy vdevice on device unbind

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: <BN9PR11MB527633CA2F698E83E12BFBD68C70A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Mon, 16 Jun 2025 05:37:58 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Aneesh Kumar K.V <aneesh.kumar@...nel.org>, Jason Gunthorpe <jgg@...pe.ca>
CC: "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Joerg Roedel
	<joro@...tes.org>, Will Deacon <will@...nel.org>, Robin Murphy
	<robin.murphy@....com>
Subject: RE: [RFC PATCH] iommufd: Destroy vdevice on device unbind

> From: Aneesh Kumar K.V <aneesh.kumar@...nel.org>
> Sent: Monday, June 16, 2025 12:29 PM
> 
> Jason Gunthorpe <jgg@...pe.ca> writes:
> 
> > On Fri, Jun 13, 2025 at 07:31:48AM +0000, Tian, Kevin wrote:
> >> yeah that seems to be the option if the said life-cycle dependency
> >> cannot be removed...
> >>
> >> conceptually it's still a bit unclean as the user needs to know that
> >> the vdevice object is special after idevice is unbound i.e. it can only
> >> be destroyed instead of supporting any other kind of operations.
> >
> > I would say userspace is somewhat malfunctioning if it destroys vfio
> > before the vdevice. So the main aim here should be to contain the
> > resulting mess, but still expect userspace to destroy the vdevice
> > without a failure.
> >
> 
> The destruction of the vdevice is triggered by the .release method of
> the iommufd file operations(iommufd_fops_release())

or by Ioctl(IOMMU_DESTROY)

> 
> and the destruction of the idevice is driven by the .release method of
> vfio cdev.
> 
>     vfio_device_fops_release()
>     → vfio_df_device_last_close()
>     → vfio_iommufd_physical_unbind()
>     → iommufd_device_unbind()
> 
> The vfio subsystem also retains a reference to the iommufd file descriptor
> through:
> 
>     vfio_df_ioctl_bind_iommufd()
>     → iommufd_ctx_from_fd()
> 
> This reference prevents the vdevice from being destroyed while the idevice
> remains bound.
> 
> So, IIUC, the current destruction flow is: first destroy vfio, and then destroy
> the vdevice?
> 

the above flow is about the userspace exiting abnormally then
the refcounting between FDs decides the destruction flow. At that
point the iommufd objects are not userspace-accessible.

the expected destruction flow from userspace is to IOMMU_DESTROY
the vdevice object before closing the vfio cdev fd which unbinds the
idevice.

now we are discussing how to handle a malfunction userspace which
violates that flow: let it be or add a tomestone state, after extending
unbind to destroy the vdevice...