linux-kernel - Re: Using Restricted DMA for virtio-pci

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: <E3EE485D-AD74-457C-BDEC-F8C62DFE4909@infradead.org>
Date: Sun, 30 Mar 2025 22:27:58 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: linuxppc-dev@...ts.ozlabs.org, "Michael S. Tsirkin" <mst@...hat.com>
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>,
 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 30 March 2025 18:06:47 BST, "Michael S. Tsirkin" <mst@...hat.com> wrote:
>> It's basically just allowing us to expose through PCI, what I believe
>> we can already do for virtio in DT.
>
>I am not saying I am against this extension.
>The idea to restrict DMA has a lot of merit outside pkvm.
>For example, with a physical devices, limiting its DMA
>to a fixed range can be good for security at a cost of
>an extra data copy.
>
>So I am not saying we have to block this specific hack.
>
>what worries me fundamentally is I am not sure it works well
>e.g. for physical virtio cards.

Not sure why it doesn't work for physical cards. They don't need to be bus-mastering; they just take data from a buffer in their own RAM.

>Attempts to pass data between devices will now also require
>extra data copies.

Yes. I think that's acceptable, but if we really cared we could perhaps extend the capability to refer to a range inside a given BAR on a specific *device*? Or maybe just *function*, and allow sharing of SWIOTLB buffer within a multi-function device?

I think it's overkill though.

>Did you think about adding an swiotlb mode to virtio-iommu at all?
>Much easier than parsing page tables.

Often the guests which need this will have a real IOMMU for the true pass-through devices. Adding a virtio-iommu into the mix (or any other system-wide way of doing something different for certain devices) is problematic.

The on-device buffer keeps it nice and simple, and even allows us to do device support for operating systems like Windows where it's a lot harder to do anything generic in the core OS.