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: <aNETcPELm72zlkwR@google.com>
Date: Mon, 22 Sep 2025 09:14:24 +0000
From: Mostafa Saleh <smostafa@...gle.com>
To: "Tian, Kevin" <kevin.tian@...el.com>
Cc: Keith Busch <kbusch@...nel.org>, Jason Gunthorpe <jgg@...pe.ca>,
	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

On Fri, Sep 19, 2025 at 07:00:04AM +0000, Tian, Kevin wrote:
> > 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.

That’s also my opinion, it seems that PASIDs are not supported in
that case, that’s why the clients share the same IOVA address space,
instead of each one having their own.
In that case I think as all of this is cooperative and can’t be enforced,
one process can corrupt another process memory that is mapped the IOMMU.

It seems to me that any memory mapped in the IOMMU is that situation
has to be explicitly shared between processes first through the kernel,
so such memory can be accessed both by CPU and DMA by both processes.

Thanks,
Mostafa