Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752770AbbKVVwj (ORCPT ); Sun, 22 Nov 2015 16:52:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36826 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752041AbbKVVwh (ORCPT ); Sun, 22 Nov 2015 16:52:37 -0500 Date: Sun, 22 Nov 2015 23:52:29 +0200 From: "Michael S. Tsirkin" To: David Woodhouse Cc: Andy Lutomirski , Benjamin Herrenschmidt , Christian Borntraeger , Paolo Bonzini , "linux-kernel@vger.kernel.org" , Martin Schwidefsky , Sebastian Ott , linux-s390 , Cornelia Huck , Joerg Roedel , Linux Virtualization , Christoph Hellwig , KVM , Marcel Apfelbaum Subject: Re: [PATCH v3 0/3] virtio DMA API core stuff Message-ID: <20151122231622-mutt-send-email-mst@redhat.com> References: <20151119153821-mutt-send-email-mst@redhat.com> <1447976286.145626.122.camel@infradead.org> <20151120085658-mutt-send-email-mst@redhat.com> <1448207908.89124.54.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1448207908.89124.54.camel@infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2539 Lines: 69 On Sun, Nov 22, 2015 at 03:58:28PM +0000, David Woodhouse wrote: > On Fri, 2015-11-20 at 10:21 +0200, Michael S. Tsirkin wrote: > > > > David, there are two things a hypervisor needs to tell the guest. > > 1. The actual device is behind an IOMMU. This is what you > > ?? are suggesting we use DMAR for. > > 2. Using IOMMU from kernel (as opposed to from userspace with VFIO) > > ?? actually adds security. For exising virtio devices on KVM, > > ?? the answer is no. And DMAR has no way to reflect that. > > Using the IOMMU from the kernel *always* adds security. It protects > against device driver (and device) bugs which can be made exploitable > by allowing DMA to anywhere in the system. No - speaking about QEMU/KVM here - you are not "allowing" DMA - by programming the virtual IOMMU you are asking the hypervisor nicely to do that. If it's buggy, it can ignore you and there's nothing you can do. As with any random change in the system, some bugs might get masked and become non-exploitable, but then some other bugs might surface and become exploitable. I gather that e.g. Xen is different. > Sure, there are classes of that which are far more interesting, for > example where you give the whole device to a guest and let it load the > firmware. But "we trust the hypervisor" and "we trust the hardware" are > not *so* far apart conceptually. Depends on the hypervisor I guess. At least for QEMU/KVM, one conceptual difference is that we actually could have the hypervisor tell us whether a specific device has to be trusted, or can be protected against, and user can actually read the code and verify that QEMU is doing the right thing. Hardware is closed source so harder to trust. > Hell, with ATS you *still* have to trust the hardware to a large > extent. > > I really think that something like the proposed DMA_ATTR_IOMMU_BYPASS > should suffice I'm not sure how that is supposed to be used - does the driver request DMA_ATTR_IOMMU_BYPASS at setup time? If yes then I think that will work for virtio - we can just set that in the driver. > for the "who cares about security; we want performance" > case. > > --? > dwmw2 > There's that, and there's an "I care about security, but do not want to burn up cycles on fake protections that do not work" case. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/