Prev: linux-next: build failure after merge of the final tree
Next: cifs: define superblock-level cache index objects and register them
From: Konrad Rzeszutek Wilk on 23 Jun 2010 12:40
> > 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: linux-next: build failure after merge of the final tree
Next: cifs: define superblock-level cache index objects and register them