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: <20250919161305.417717-1-amastro@fb.com>
Date: Fri, 19 Sep 2025 09:13:04 -0700
From: Alex Mastro <amastro@...com>
To: Jason Gunthorpe <jgg@...pe.ca>
CC: Alex Mastro <amastro@...com>,
        Alex Williamson
	<alex.williamson@...hat.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, Sep 18, 2025 at 07:57:39PM -0300, Jason Gunthorpe wrote:
> I'm having a somewhat hard time wrapping my head around the security
> model that says your trust your related processes not use DMA in a way
> that is hostile their peers, but you don't trust them not to issue
> hostile ioctls..

Ah, yea. In my original message, I should have emphasized that vending the
entire vfio device fd confers access to inappropriate ioctls *in addition to*
inappropriate BAR regions that the client should be restricted from accessing.

Assuming we make headway on dma_buf_ops.mmap, granting a client process access
to a dma-buf's worth of BAR space does not feel spiritually different than
granting it to a peer device. The onus is on the combination of driver + device
policy to constrain the side-effects of foreign access to the exposed BAR
sub-regions.

Please let me know if I misunderstood your meaning.

> IIRC VFIO should allow partial BAR mappings, so the client process can
> robustly have a subset mapped if you trust it to perform the unix
> SCM_RIGHTS/mapping ioctl/close() sequence.

Yes -- we already do this today actually. The USD just tells the client "these
are the specific set of (offset, length) within the vfio device fd you should
mmap". Those intervals are slices within BARs.

> > > Instead of vending the VFIO device fd to the client process, the USD could bind
> > the necessary BAR regions to a dma-buf fd and share that with the client. If
> > VFIO supported dma_buf_ops.mmap, the client could mmap those into its address
> > space.
> 
> I wouldn't object to this, I think it is not too complicated at all.

That's encouraging to hear! Thank you.

> 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.

This seems totally reasonable to me.

> 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.

Agreed. If we can engineer BPF to be able to interact with those ioctls to hoist
these kinds of policy decisions up into user space, I can't argue with that.

> I don't think viommu is really related to this, viommu is more about
> multiple physical devices.

Ack. I wasn't sure how much to read into the "representing a slice of the
physical IOMMU instance" comment [1].

[1] https://docs.kernel.org/userspace-api/iommufd.html

Thanks,
Alex