linux-kernel - Re: [TECH TOPIC] vfio, iommufd: Enabling user space drivers to vend more granular access to client processes

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] [day] [month] [year] [list]

Message-ID: <20250919171459.1352524-1-amastro@fb.com>
Date: Fri, 19 Sep 2025 10:14:58 -0700
From: Alex Mastro <amastro@...com>
To: Alex Williamson <alex.williamson@...hat.com>
CC: Alex Mastro <amastro@...com>, Jason Gunthorpe <jgg@...pe.ca>,
        Kevin Tian
	<kevin.tian@...el.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>, David Reiss
	<dreiss@...a.com>,
        Joerg Roedel <joro@...tes.org>, Keith Busch
	<kbusch@...nel.org>,
        Leon Romanovsky <leon@...nel.org>, Li Zhe
	<lizhe.67@...edance.com>,
        Mahmoud Adam <mngyadam@...zon.de>,
        Philipp Stanner
	<pstanner@...hat.com>,
        Robin Murphy <robin.murphy@....com>,
        Vivek Kasireddy
	<vivek.kasireddy@...el.com>,
        Will Deacon <will@...nel.org>, Yunxiang Li
	<Yunxiang.Li@....com>,
        <linux-kernel@...r.kernel.org>, <iommu@...ts.linux.dev>,
        <kvm@...r.kernel.org>
Subject: Re: [TECH TOPIC] vfio, iommufd: Enabling user space drivers to vend more granular access to client processes

On Fri, Sep 19, 2025 at 09:57:43AM -0600, Alex Williamson wrote:
> Definitely.  Also, is this at all considering the work that's gone into
> vfio-user?  The long running USD sounds a lot like a vfio-user server,
> where if we're using vfio-user's socket interface we'd have a lot of
> opportunity to implement policy there and dma-bufs might be a means to
> expose direct, restricted access.  Thanks,

Possibly. Though I think the USD's responsibilities and the semantics for
how clients would negotiate various forms of device access would be very
application-dependent. In addition to just vending vfio and iommu-related fds,
our USD needs to do things like bootstrap the device by loading firmwares,
collect metrics, and other background functionality.

I'm not sure if I'm addressing your point though.

We actually do use libvfio-user [1] for user space simulation of PCI devices,
but it's not a part of our USD today.

[1] https://github.com/nutanix/libvfio-user

Alex