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: <20250624181249.GD72557@ziepe.ca>
Date: Tue, 24 Jun 2025 15:12:49 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Alex Williamson <alex.williamson@...hat.com>
Cc: Alex Mastro <amastro@...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 Tue, Jun 24, 2025 at 10:23:03AM -0600, Alex Williamson wrote:

> I think we're specifically trying to gain visibility to the
> anon_inode:[vfio-device] in the legacy case.

Ah, I see.. 

> The @name passed to anon_inode_getfile_fmode() is described as the name
> of the "class", which is why I think we used the static
> "[vfio-device]", but I see KVM breaks the mold, adding the vcpu_id:
> 
> 	snprintf(name, sizeof(name), "kvm-vcpu-stats:%d", vcpu->vcpu_id);
> 
> We could do something similar, but maybe fdinfo is the better option,
> and if it is then dev_name() seems like the useful thing to add there
> (though we could add more than one thing).

I wouldn't encode a sysfspath (which is what you really need for a
device name) in the [] section.. fdinfo makes sense for that, but I
would return the full sysfs path to the device from the core code
rather than try to return just the BDF for PCI.

Prefix /sys/ and then userspace can inspect the directory for whatever
information it needs.

It could also return a %d within the [] that indicated which group it
was for. In most system that will tell you the device anyhow since
groups are singular.

> I don't recall if or how we accounted for the concept of vf_tokens in
> the cdev model and I don't see evidence that we did.  For instance
> vfio_pci_validate_vf_token() is only called from vfio_pci_core_match(),
> which is called as match through the vfio_device_ops, but only from
> vfio_group_ioctl_get_device_fd().  So using cdev, it appears we don't
> have the same opt-in requirement when using a VF where the PF is
> managed by a vfio-pci userspace driver.  Thanks,

Hmm.. I can't recall.

I wrote a small patch to correct this, I will post it.

Jason