Message-ID: <979b6a34ca5724ced1d4871b58bf227065d7da57.camel@infradead.org>
Date: Fri, 21 Mar 2025 15:38:10 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: 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>
Cc: 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, "Michael S. Tsirkin" <mst@...hat.com>, 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: Using Restricted DMA for virtio-pci

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? :)

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)

Powered by blists - more mailing lists