From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-s390 <linux-s390@vger.kernel.org>,
Joerg Roedel <jroedel@suse.de>, KVM <kvm@vger.kernel.org>,
benh@kernel.crashing.org,
Sebastian Ott <sebott@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
Christian Borntraeger <borntraeger@de.ibm.com>,
Andy Lutomirski <luto@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Christoph Hellwig <hch@lst.de>,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH v3 0/3] virtio DMA API core stuff
Date: Wed, 28 Oct 2015 16:05:10 +0200 [thread overview]
Message-ID: <20151028155105-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <1446039327.3405.216.camel@infradead.org>
On Wed, Oct 28, 2015 at 10:35:27PM +0900, David Woodhouse wrote:
> On Wed, 2015-10-28 at 13:35 +0200, Michael S. Tsirkin wrote:
> > E.g. on intel x86, there's an option iommu=pt which does the 1:1
> > thing for devices when used by kernel, but enables
> > the iommu if used by userspace/VMs.
>
> That's none of your business.
>
> You call the DMA API when you do DMA. That's all there is to it.
>
> If the IOMMU happens to be in passthrough mode, or your device happens
> to not to be routed through an IOMMU today, then I/O virtual address
> you get back from the DMA API will look a *lot* like the physical
> address you asked the DMA to map. You might think there's no IOMMU. We
> couldn't possibly comment.
>
> Use the DMA API. Always. Let the platform worry about whether it
> actually needs to *do* anything or not.
> --
> dwmw2
>
>
Short answer - platforms need a way to discover, and express different
security requirements of different devices. If they continue to lack
that, we'll need a custom API in virtio, and while this seems a bit less
elegant, I would not see that as the end of the world at all, there are
not that many virtio drivers.
And hey - that's just an internal API. We can change it later at a whim.
Long answer - PV is weird. It's not always the same as real hardware.
For PV, it's generally hypervisor doing writes into memory.
If it's monolitic with device emulation in same memory space as the
hypervisor (e.g. in the case of the current QEMU, or using vhost in host
kernel), then you gain *no security* by "restricting" it by means of the
IOMMU - the IOMMU is part of the same hypervisor.
If it is modular with device emulation in a separate memory space (e.g.
in case of Xen, or vhost-user in modern QEMU) then you do gain security:
the part emulating the IOMMU limits the part doing DMA.
In both cases for assigned devices, it is always modular in a sense, so
you do gain security since that is restricted by the hardware IOMMU.
The way things are set up at the moment, it's mostly global,
with iommu=pt on intel being a kind of exception.
We need host/guest and API interfaces that are more nuanced than that.
--
MST
next prev parent reply other threads:[~2015-10-28 14:05 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1446014204.git.luto@kernel.org>
2015-10-28 6:38 ` [PATCH v3 1/3] virtio_net: Stop doing DMA from the stack Andy Lutomirski
2015-10-28 6:38 ` [PATCH v3 2/3] virtio_ring: Support DMA APIs Andy Lutomirski
2015-10-28 6:39 ` [PATCH v3 3/3] virtio_pci: Use the DMA API Andy Lutomirski
2015-10-28 6:53 ` [PATCH v3 0/3] virtio DMA API core stuff David Woodhouse
2015-10-28 7:09 ` Andy Lutomirski
[not found] ` <a2b5cd8102594565dca91e9ed665ae2fff5367bb.1446014204.git.luto@kernel.org>
2015-10-28 7:08 ` [PATCH v3 1/3] virtio_net: Stop doing DMA from the stack Michael S. Tsirkin
2015-10-28 7:17 ` [PATCH v3 0/3] virtio DMA API core stuff Michael S. Tsirkin
2015-10-28 7:40 ` Christian Borntraeger
2015-10-28 8:09 ` David Woodhouse
2015-10-28 11:35 ` Michael S. Tsirkin
2015-10-28 13:35 ` David Woodhouse
2015-10-28 14:05 ` Michael S. Tsirkin [this message]
2015-10-28 14:13 ` David Woodhouse
2015-10-28 14:22 ` Michael S. Tsirkin
2015-10-28 14:32 ` David Woodhouse
2015-10-28 16:12 ` Michael S. Tsirkin
[not found] ` <20151028175136-mutt-send-email-mst@redhat.com>
2015-10-28 22:51 ` Andy Lutomirski
2015-10-29 9:01 ` Michael S. Tsirkin
2015-10-29 16:18 ` David Woodhouse
2015-11-08 10:37 ` Michael S. Tsirkin
2015-11-08 11:49 ` Joerg Roedel
2015-11-10 15:02 ` Michael S. Tsirkin
2015-11-10 18:54 ` Andy Lutomirski
2015-11-11 10:05 ` Michael S. Tsirkin
2015-11-11 15:56 ` Andy Lutomirski
[not found] ` <CALCETrWmZaQxS3-r9jsUb3BPhdLRbRrdZWok2geHnYKaWC4YKA@mail.gmail.com>
2015-11-11 22:30 ` David Woodhouse
[not found] ` <1447281027.3513.11.camel@infradead.org>
2015-11-12 11:09 ` Michael S. Tsirkin
2015-11-12 12:18 ` David Woodhouse
2015-11-22 13:06 ` Marcel Apfelbaum
2015-11-22 15:54 ` David Woodhouse
2015-11-22 17:04 ` Marcel Apfelbaum
2015-11-22 22:11 ` Michael S. Tsirkin
2015-11-08 12:00 ` David Woodhouse
2015-10-30 15:16 ` Joerg Roedel
2015-10-30 16:54 ` David Woodhouse
2015-11-03 10:24 ` Paolo Bonzini
[not found] ` <20151030151612.GB2704@suse.de>
2015-11-11 9:11 ` Michael S. Tsirkin
2015-10-28 8:36 ` Benjamin Herrenschmidt
2015-10-28 11:23 ` Michael S. Tsirkin
2015-10-28 13:37 ` David Woodhouse
2015-10-28 14:07 ` Michael S. Tsirkin
2015-11-19 13:45 ` Michael S. Tsirkin
[not found] ` <20151119153821-mutt-send-email-mst@redhat.com>
2015-11-19 21:59 ` Andy Lutomirski
2015-11-19 23:38 ` David Woodhouse
2015-11-20 2:56 ` Benjamin Herrenschmidt
2015-11-20 8:34 ` Michael S. Tsirkin
2015-11-20 8:21 ` Michael S. Tsirkin
2015-11-22 15:58 ` David Woodhouse
[not found] ` <1448207908.89124.54.camel@infradead.org>
2015-11-22 21:52 ` Michael S. Tsirkin
[not found] ` <20151122231622-mutt-send-email-mst@redhat.com>
2015-11-22 22:21 ` David Woodhouse
2015-11-23 7:56 ` Michael S. Tsirkin
2015-11-22 22:21 ` David Woodhouse
2015-11-20 6:56 ` Michael S. Tsirkin
2015-11-20 7:47 ` Michael S. Tsirkin
2015-10-28 6:38 Andy Lutomirski
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=20151028155105-mutt-send-email-mst@redhat.com \
--to=mst@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=borntraeger@de.ibm.com \
--cc=dwmw2@infradead.org \
--cc=hch@lst.de \
--cc=jroedel@suse.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=luto@kernel.org \
--cc=pbonzini@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=sebott@linux.vnet.ibm.com \
--cc=virtualization@lists.linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).