Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753536Ab2FJQJm (ORCPT ); Sun, 10 Jun 2012 12:09:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8030 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752597Ab2FJQJl (ORCPT ); Sun, 10 Jun 2012 12:09:41 -0400 Message-ID: <1339344566.26976.272.camel@ul30vt> Subject: Re: [PATCH] uio_pci_generic does not export memory resources From: Alex Williamson To: "Michael S. Tsirkin" Cc: "Hans J. Koch" , Andreas Hartmann , Dominic Eschweiler , Jan Kiszka , Greg Kroah-Hartman , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Date: Sun, 10 Jun 2012 10:09:26 -0600 In-Reply-To: <20120610141759.GB8922@redhat.com> References: <1339156616.3870.9.camel@blech> <20120608130351.GB1964@redhat.com> <4FD1FB49.3020905@siemens.com> <1339165009.26976.60.camel@ul30vt> <1339166867.3870.29.camel@blech> <4FD22552.6090609@01019freenet.de> <20120608164426.GE9705@local> <1339175476.26976.102.camel@ul30vt> <20120610141759.GB8922@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2137 Lines: 44 On Sun, 2012-06-10 at 17:18 +0300, Michael S. Tsirkin wrote: > On Fri, Jun 08, 2012 at 11:11:16AM -0600, Alex Williamson wrote: > > On Fri, 2012-06-08 at 18:44 +0200, Hans J. Koch wrote: > > > On Fri, Jun 08, 2012 at 06:16:18PM +0200, Andreas Hartmann wrote: > > > > Hi Dominic, > > > > > > > > Dominic Eschweiler wrote: > > > > > Am Freitag, den 08.06.2012, 08:16 -0600 schrieb Alex Williamson: > > > > >> Yes, thanks Jan. This is exactly what VFIO does. VFIO provides > > > > >> secure config space access, resource access, DMA mapping services, and > > > > >> full interrupt support to userspace. > > > > > > VFIO is not a "better UIO". It *requires* an IOMMU. Dominic didn't say on > > > what CPU he's working, so it's not clear if he can use VFIO at all. > > > > > > UIO is intended for general use with devices that have mappable registers > > > and don't fit into any other subsystem. No more, no less. > > > > VFIO is a secure UIO. > > A secure UIO *for VFs*. I think that's why it's called VFIO :). > Other stuff sometimes also works but no real guarantees, though > VFIO tries to make sure you don't burn yourself too badly > if it breaks. We do a little better than that. Multifunction devices that don't explicitly report ACS support are grouped together, so we have security for multifunction devices as well. Either single of multifunction PFs can have an option ROM, but since there's no defined mechanism to program the ROM, we can't protect it. Secure boot actually helps us here since the ROM loaded by the host BIOS or drivers would need to verify the ROM before using it. Note that secure boot will likely close off the pci-sysfs path uio_pci and KVM device assignment use to get resources since it allows unprotected access to the system. VFIO provides an interface where we control secure access, so should be compatible with secure boot. Thanks, Alex -- 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/