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

Message-ID: <20250919095743.482a00cd.alex.williamson@redhat.com>
Date: Fri, 19 Sep 2025 09:57:43 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Alex Mastro <amastro@...com>, 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 Thu, 18 Sep 2025 19:57:39 -0300
Jason Gunthorpe <jgg@...pe.ca> wrote:
> 
> What I've been thinking is if the vending process could "dup" the FD
> and permanently attach a BPF program to the new FD that sits right
> after ioctl. The BPF program would inspect each ioctl when it is
> issued and enforce whatever policy the vending process wants.

Promising idea.

> What would give me alot of pause is your proposal where we effectively
> have the kernel enforce some arbitary policy, and I know from
> experience there will be endless asks for more and more policy
> options.

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,

Alex