Re: [PATCH] uio_pci_generic does not export memory resources

[Alex Williamson <alex.williamson@redhat.com>]

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