Re: [PATCH] uio_pci_generic does not export memory resources

["Michael S. Tsirkin" <mst@redhat.com>]

On Sun, Jun 10, 2012 at 10:09:26AM -0600, Alex Williamson wrote:
> 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.

How can you get security with insecure hardware?

So you prevent the device from writing to host memory? Cool.
Now guest puts a virus on an on-card flash, the
moment device is assigned to another VM it will own that,
or host if it's enabled in host.

I can make up more silliness.  Buggy userspace can brick the device,
e.g. by damaging the internal eeprom memory, and these things were known
to happen even by accident.

Simply put if you want secure userspace drivers you must be able to
trust your hardware for security and the only hardware that promises you
security is a VF in an SRIOV device.

> 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

IMHO all this means VFIO *works* not just for VFs.
Not that it's secure.

-- 
MST