linux-kernel - Re: [PATCH] vfio/pci: print vfio-device name to fdinfo

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: <20250624163559.2984626-1-amastro@fb.com>
Date: Tue, 24 Jun 2025 09:35:58 -0700
From: Alex Mastro <amastro@...com>
To: Jason Gunthorpe <jgg@...pe.ca>
CC: Alex Mastro <amastro@...com>,
        Alex Williamson
	<alex.williamson@...hat.com>, <peterx@...hat.com>,
        <kbusch@...nel.org>, <kvm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] vfio/pci: print vfio-device name to fdinfo

On Mon, 23 Jun 2025 21:56:05 -0300 Jason Gunthorpe <jgg@...pe.ca> wrote:
> For the legacy route this effectively gives you the iommu group.

This is true, but
- There could be multiple devices per group, and I can't see a good way to
  determine exactly which one is in use. (we happen to have one device per
  group, so this particular concern is somewhat moot for us)
- In our use case, we vend the vfio device fd via SCM_RIGHTS to other processes
  which did not open the group fd. We keep track of this internally, but it's an
  imperfect solution, and we'd like a more fundamental way to query the kernel
  for this.

> For the new route this will give you the struct device.
> 
> The userspace can deduce more information, like the actual PCI BDF, by
> mapping the name through sysfs.

In the vfio cdev case, <pci sysfs path>/vfio-dev/X tells you the
/dev/vfio/devices/X mapping, but is there a straightforward way to map in the
opposite direction?

I'm open to other approaches to solving the issue, but making an additive change
to fdinfo seemed innocuous enough, and hopefully unlikely to be incompatible
with future direction of this subsystem.

Thanks,
Alex