All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: "Claire Chang" <tientzu@chromium.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	mpe@ellerman.id.au, "Joerg Roedel" <joro@8bytes.org>,
	"Will Deacon" <will@kernel.org>,
	"Frank Rowand" <frowand.list@gmail.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	boris.ostrovsky@oracle.com, jgross@suse.com,
	"Christoph Hellwig" <hch@lst.de>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	heikki.krogerus@linux.intel.com, peterz@infradead.org,
	benh@kernel.crashing.org, grant.likely@arm.com, paulus@samba.org,
	mingo@kernel.org, sstabellini@kernel.org,
	"Saravana Kannan" <saravanak@google.com>,
	xypron.glpk@gmx.de,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	"Bartosz Golaszewski" <bgolaszewski@baylibre.com>,
	xen-devel@lists.xenproject.org,
	"Thierry Reding" <treding@nvidia.com>,
	linux-devicetree <devicetree@vger.kernel.org>,
	linuxppc-dev@lists.ozlabs.org,
	"Nicolas Boichat" <drinkcat@chromium.org>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Greg KH" <gregkh@linuxfoundation.org>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	"Jim Quinlan" <james.quinlan@broadcom.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	hch@infradead.org, "Jason Wang" <jasowang@redhat.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	virtualization@lists.linux.dev, graf@amazon.de
Subject: Re: Using Restricted DMA for virtio-pci
Date: Fri, 21 Mar 2025 14:32:24 -0400	[thread overview]
Message-ID: <20250321142947-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <979b6a34ca5724ced1d4871b58bf227065d7da57.camel@infradead.org>

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



  reply	other threads:[~2025-03-21 18:33 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09  6:21 [PATCH v4 00/14] Restricted DMA Claire Chang
2021-02-09  6:21 ` Claire Chang
2021-02-09  6:21 ` Claire Chang
2021-02-09  6:21 ` [PATCH v4 01/14] swiotlb: Remove external access to io_tlb_start Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  8:40   ` Christoph Hellwig
2021-02-09  8:40     ` Christoph Hellwig
2021-02-09 11:17   ` kernel test robot
2021-02-09  6:21 ` [PATCH v4 02/14] swiotlb: Move is_swiotlb_buffer() to swiotlb.c Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21 ` [PATCH v4 03/14] swiotlb: Add struct swiotlb Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21 ` [PATCH v4 04/14] swiotlb: Refactor swiotlb_late_init_with_tbl Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21 ` [PATCH v4 05/14] swiotlb: Add DMA_RESTRICTED_POOL Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21 ` [PATCH v4 06/14] swiotlb: Add restricted DMA pool Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  9:39   ` kernel test robot
2021-02-09  9:56   ` kernel test robot
2021-02-09 11:39   ` kernel test robot
2021-02-09  6:21 ` [PATCH v4 07/14] swiotlb: Update swiotlb API to gain a struct device argument Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21 ` [PATCH v4 08/14] swiotlb: Use restricted DMA pool if available Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21 ` [PATCH v4 09/14] swiotlb: Refactor swiotlb_tbl_{map,unmap}_single Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  9:31   ` [PATCH v4 09/14] swiotlb: Refactor swiotlb_tbl_{map, unmap}_single kernel test robot
2021-02-09  6:21 ` [PATCH v4 10/14] dma-direct: Add a new wrapper __dma_direct_free_pages() Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21 ` [PATCH v4 11/14] swiotlb: Add is_dev_swiotlb_force() Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21 ` [PATCH v4 12/14] swiotlb: Add restricted DMA alloc/free support Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-26  4:17   ` Claire Chang
2021-02-26  4:17     ` Claire Chang
2021-02-26  4:17     ` Claire Chang
2021-02-26  5:17     ` Christoph Hellwig
2021-02-26  5:17       ` Christoph Hellwig
2021-02-26  5:17       ` Christoph Hellwig
2021-02-26  9:35       ` Claire Chang
2021-02-26  9:35         ` Claire Chang
2021-02-26  9:35         ` Claire Chang
2021-02-09  6:21 ` [PATCH v4 13/14] dt-bindings: of: Add restricted DMA pool Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-03-10 16:07   ` Will Deacon
2021-03-10 16:07     ` Will Deacon
2021-03-10 16:07     ` Will Deacon
2021-03-10 21:40     ` Rob Herring
2021-03-10 21:40       ` Rob Herring
2021-03-10 21:40       ` Rob Herring
2021-03-11  5:04       ` Florian Fainelli
2021-03-11  5:04         ` Florian Fainelli
2021-03-11  5:04         ` Florian Fainelli
2021-02-09  6:21 ` [PATCH v4 14/14] of: Add plumbing for " Claire Chang
2021-02-09  6:21   ` Claire Chang
2021-04-22  8:20 ` [PATCH v4 00/14] Restricted DMA Claire Chang
2021-04-22  8:20   ` Claire Chang
2021-04-22  8:20   ` Claire Chang
2025-03-21 15:38 ` Using Restricted DMA for virtio-pci David Woodhouse
2025-03-21 18:32   ` Michael S. Tsirkin [this message]
2025-03-21 18:42     ` David Woodhouse
2025-03-28 17:40       ` David Woodhouse
2025-03-30 13:42         ` Michael S. Tsirkin
2025-03-30 15:07           ` David Woodhouse
2025-03-30 16:59             ` Michael S. Tsirkin
2025-03-30 20:07               ` David Woodhouse
2025-03-30 17:06       ` Michael S. Tsirkin
2025-03-30 21:27         ` David Woodhouse
2025-03-30 21:48           ` Michael S. Tsirkin
2025-03-31  9:42             ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250321142947-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=benh@kernel.crashing.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=dwmw2@infradead.org \
    --cc=eperezma@redhat.com \
    --cc=frowand.list@gmail.com \
    --cc=graf@amazon.de \
    --cc=grant.likely@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=james.quinlan@broadcom.com \
    --cc=jasowang@redhat.com \
    --cc=jgross@suse.com \
    --cc=joro@8bytes.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=saravanak@google.com \
    --cc=sstabellini@kernel.org \
    --cc=tientzu@chromium.org \
    --cc=treding@nvidia.com \
    --cc=virtualization@lists.linux.dev \
    --cc=will@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xuanzhuo@linux.alibaba.com \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.