Message-ID: <20250321142947-mutt-send-email-mst@kernel.org>
Date: Fri, 21 Mar 2025 14:32:24 -0400
From: "Michael S. Tsirkin" <mst@...hat.com>
To: David Woodhouse <dwmw2@...radead.org>
Cc: Claire Chang <tientzu@...omium.org>, Rob Herring <robh+dt@...nel.org>,
	mpe@...erman.id.au, Joerg Roedel <joro@...tes.org>,
	Will Deacon <will@...nel.org>,
	Frank Rowand <frowand.list@...il.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	boris.ostrovsky@...cle.com, jgross@...e.com,
	Christoph Hellwig <hch@....de>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	heikki.krogerus@...ux.intel.com, peterz@...radead.org,
	benh@...nel.crashing.org, grant.likely@....com, paulus@...ba.org,
	mingo@...nel.org, sstabellini@...nel.org,
	Saravana Kannan <saravanak@...gle.com>, xypron.glpk@....de,
	"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
	Bartosz Golaszewski <bgolaszewski@...libre.com>,
	xen-devel@...ts.xenproject.org, Thierry Reding <treding@...dia.com>,
	linux-devicetree <devicetree@...r.kernel.org>,
	linuxppc-dev@...ts.ozlabs.org,
	Nicolas Boichat <drinkcat@...omium.org>,
	Dan Williams <dan.j.williams@...el.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	lkml <linux-kernel@...r.kernel.org>,
	"list@....net:IOMMU DRIVERS" <iommu@...ts.linux-foundation.org>,
	Jim Quinlan <james.quinlan@...adcom.com>,
	Robin Murphy <robin.murphy@....com>, hch@...radead.org,
	Jason Wang <jasowang@...hat.com>,
	Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
	Eugenio Pérez <eperezma@...hat.com>,
	virtualization@...ts.linux.dev, graf@...zon.de
Subject: Re: Using Restricted DMA for virtio-pci

On Fri, Mar 21, 2025 at 03:38:10PM +0000, David Woodhouse wrote:
> On Tue, 2021-02-09 at 14:21 +0800, Claire Chang wrote:
> > This series implements mitigations for lack of DMA access control on
> > systems without an IOMMU, which could result in the DMA accessing the
> > system memory at unexpected times and/or unexpected addresses, possibly
> > leading to data leakage or corruption.
> 
> Replying to an ancient (2021) thread which has already been merged...
> 
> I'd like to be able to use this facility for virtio devices.
> 
> Virtio already has a complicated relationship with the DMA API, because
> there were a bunch of early VMM bugs where the virtio devices where
> magically exempted from IOMMU protection, but the VMM lied to the guest
> and claimed they weren't.
> 
> With the advent of confidential computing, and the VMM (or whatever's
> emulating the virtio device) not being *allowed* to arbitrarily access
> all of the guest's memory, the DMA API becomes necessary again.
> 
> Either a virtual IOMMU needs to determine which guest memory the VMM
> may access, or the DMA API is wrappers around operations which
> share/unshare (or unencrypt/encrypt) the memory in question.
> 
> All of which is complicated and slow, if we're looking at a minimal
> privileged hypervisor stub like pKVM which enforces the lack of guest
> memory access from VMM.
> 
> I'm thinking of defining a new type of virtio-pci device which cannot
> do DMA to arbitrary system memory. Instead it has an additional memory
> BAR which is used as a SWIOTLB for bounce buffering.
> 
> The driver for it would look much like the existing virtio-pci device
> except that it would register the restricted-dma region first (and thus
> the swiotlb dma_ops), and then just go through the rest of the setup
> like any other virtio device.
> 
> That seems like it ought to be fairly simple, and seems like a
> reasonable way to allow an untrusted VMM to provide virtio devices with
> restricted DMA access.
> 
> While I start actually doing the typing... does anyone want to start
> yelling at me now? Christoph? mst? :)


I don't mind as such (though I don't understand completely), but since
this is changing the device anyway, I am a bit confused why you can't
just set the VIRTIO_F_ACCESS_PLATFORM feature bit?  This forces DMA API
which will DTRT for you, will it not?

-- 
MST

Powered by blists - more mailing lists