From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966111AbbJ1OGe (ORCPT ); Wed, 28 Oct 2015 10:06:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37438 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030276AbbJ1OFR (ORCPT ); Wed, 28 Oct 2015 10:05:17 -0400 Date: Wed, 28 Oct 2015 16:05:10 +0200 From: "Michael S. Tsirkin" To: David Woodhouse Cc: Christian Borntraeger , Andy Lutomirski , linux-kernel@vger.kernel.org, Joerg Roedel , Cornelia Huck , Sebastian Ott , Paolo Bonzini , Christoph Hellwig , benh@kernel.crashing.org, KVM , Martin Schwidefsky , linux-s390 , virtualization@lists.linux-foundation.org Subject: Re: [PATCH v3 0/3] virtio DMA API core stuff Message-ID: <20151028155105-mutt-send-email-mst@redhat.com> References: <20151028091208-mutt-send-email-mst@redhat.com> <56307BD1.6010806@de.ibm.com> <1446019787.3405.203.camel@infradead.org> <20151028132331-mutt-send-email-mst@redhat.com> <1446039327.3405.216.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1446039327.3405.216.camel@infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH v3 0/3] virtio DMA API core stuff Date: Wed, 28 Oct 2015 16:05:10 +0200 Message-ID: <20151028155105-mutt-send-email-mst@redhat.com> References: <20151028091208-mutt-send-email-mst@redhat.com> <56307BD1.6010806@de.ibm.com> <1446019787.3405.203.camel@infradead.org> <20151028132331-mutt-send-email-mst@redhat.com> <1446039327.3405.216.camel@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1446039327.3405.216.camel@infradead.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Archive: List-Post: To: David Woodhouse Cc: linux-s390 , Joerg Roedel , KVM , benh@kernel.crashing.org, Sebastian Ott , linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Christian Borntraeger , Andy Lutomirski , Paolo Bonzini , Christoph Hellwig , Martin Schwidefsky List-ID: 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