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: <yq5abjqotim7.fsf@kernel.org>
Date: Mon, 16 Jun 2025 09:58:48 +0530
From: Aneesh Kumar K.V <aneesh.kumar@...nel.org>
To: Jason Gunthorpe <jgg@...pe.ca>, "Tian, Kevin" <kevin.tian@...el.com>
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

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())

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?

>
>> hmm if the user needs to build certain knowledge anyway can we 
>> go one step further to state that the vdevice will be destroyed
>> automatically once its idevice is unbound so the user shouldn't
>> attempt to explicitly destroy it again after unbind?
>
> I would assume a malfunctioning userspace is probably going to destroy
> the vdevice explicitly. If it had proper knowledge it wouldn't have
> done this in the first place :)
>
> Jason

-aneesh