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: <BN9PR11MB5276D7D2BF13374EEA2C788F8C11A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Fri, 19 Sep 2025 07:00:04 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Keith Busch <kbusch@...nel.org>, Jason Gunthorpe <jgg@...pe.ca>
CC: Alex Mastro <amastro@...com>, Alex Williamson
	<alex.williamson@...hat.com>, Bjorn Helgaas <bhelgaas@...gle.com>, "David
 Reiss" <dreiss@...a.com>, Joerg Roedel <joro@...tes.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>, "Kasireddy, Vivek" <vivek.kasireddy@...el.com>, "Will
 Deacon" <will@...nel.org>, Yunxiang Li <Yunxiang.Li@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>
Subject: RE: [TECH TOPIC] vfio, iommufd: Enabling user space drivers to vend
 more granular access to client processes

> From: Keith Busch <kbusch@...nel.org>
> Sent: Friday, September 19, 2025 7:25 AM
> 
> On Thu, Sep 18, 2025 at 07:57:39PM -0300, Jason Gunthorpe wrote:
> > On Thu, Sep 18, 2025 at 02:44:07PM -0700, Alex Mastro wrote:
> >
> > > We anticipate a growing need to provide more granular access to device
> resources
> > > beyond what the kernel currently affords to user space drivers similar to
> our
> > > model.
> >
> > 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..
> 
> I read this as more about having the granularity to automatically
> release resources associated with a client process when it dies (as
> mentioned below) rather than relying on the bootstrapping process to
> manage it all. Not really about hostile ioctls, but that an ungraceful
> ending of some client workload doesn't even send them.
> 

the proposal includes two parts: BAR access and IOMMU mapping. For
the latter looks the intention is more around releasing resource. But
the former sounds more like a security enhancement - instead of
granting the client full access to the entire device it aims to expose
only a region of BAR resource necessary into guest. Then as Jason
questioned what is the value of doing so when one client can program
arbitrary DMA address into the exposed BAR region to attack mapped
memory of other clients and the USD... there is no hw isolation 
within a partitioned IOAS unless the device supports PASID then 
each client can be associated to its own IOAS space.