Re: [PATCH] Xen-SWIOTBL v0.8.3 used for Xen PCI pass through for PV guests.

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

> > The end user of this is the Xen PCI frontend and Xen PCI [1] which
> > require a DMA API "backend" that understands Xen's MMU. This allows the
> > PV domains to use PCI devices.
> 
> Hi Konrad,

Hey Alex,

Congratulations on your new job at Red Hat!
> 
> Sorry if I missed it, but I didn't see any mention or apparent
> requirement of a hardware iommu in xen for this code.  Is that true?  If

Ah, I completely missed to put that in the writeup (and as well some
other things that I thought off overnight). The answer is: both.

You can run this without an IOMMU in which case the security threat you
mentioned is feasible. Or you can run with an hardware IOMMU, if you
pass in the iommu=pv argument to the Xen hypervisor.

> so, is there anything to stop a PV guest with ownership of a DMA capable
> PCI device from reading all sorts of memory that the domain wouldn't
> otherwise have access to?  I was under the impression that the old PCI
> front/back for PV guests was mainly an interesting hack with limited
> applications due to security.  Thanks,

I thought as well but it looks as many folks are using it. The other
thing that I forgot to mention in the writeup are these two other use cases:

 1) One of them is the privileged PV (PPV?) domain drivers. This
    idea came about a year ago and was suggested on LKML by Eric
    Biederman. I can't find the link to it thought. Eric,
    would you by any chance remember it?

    The idea is to have multiple PPV domains which serve specific
    device drivers. An implementation using the hardware IOMMU is the
    Qubes OS (http://quebes-os.org), while this would be the same but
    using PV guests.

 2) Xen Dom0 support. Without the SWIOTLB-Xen patchset Dom0 is incapable
    of working with PCI devices.