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: <BN9PR11MB527606182417BB7A35349F598C74A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Thu, 12 Jun 2025 08:05:37 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@...nel.org>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Jason Gunthorpe <jgg@...pe.ca>, 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 (Arm) <aneesh.kumar@...nel.org>
> Sent: Tuesday, June 10, 2025 2:52 PM
> 
> The iommufd subsystem uses the VFIO character device descriptor to bind

it's the 'user' or 'vmm' initiating that operation, not the subsystem itself.

> a device file to an iommufd context via the VFIO_DEVICE_BIND_IOMMUFD
> ioctl. This binding returns a bind_id, which is then used in subsequent

there is no 'bind_id' in any uAPI. let's stick to 'devid'.

> iommufd ioctls such as IOMMU_HWPT_ALLOC, IOMMU_VIOMMU_ALLOC,
> and
> IOMMU_VDEVICE_ALLOC.
> 
> Among these, IOMMU_VDEVICE_ALLOC is special—the lifetime of a virtual
> device (vdevice) should be tied to the bound state of its physical
> device.
> 
> In the current kernel, there is no enforced dependency between
> iommufd_device and iommufd_vdevice. This patch introduces such a
> dependency: when the device is unbound, the associated vdevice is now
> automatically destroyed.

This went backward.

The initial v5 patch [1] from Nicolin was similar to what this
patch does. Jason explained [2] why it's unsafe to destroy "userspace
created" objects behind the scene. And a general rule in iommufd is
to not take long term references on kernel owned objects.

[1] https://lore.kernel.org/all/53025c827c44d68edb6469bfd940a8e8bc6147a5.1729897278.git.nicolinc@nvidia.com/
[2] https://lore.kernel.org/all/20241029184801.GW6956@nvidia.com/

> 
> Although there is already an implicit dependency—vdevices can only be
> destroyed after the iommufd_device is unbound due to the VFIO cdev file
> descriptor holding a reference to the iommu file descriptor—this patch

I didn't get this part. The user owns the life cycle of its created objects.
We don't have such restriction that a vdevice object can be destroyed
only after device is unbound...