WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [kvm-devel] [Xen-devel] More virtio users

To: "Arnd Bergmann" <arnd@xxxxxxxx>
Subject: RE: [kvm-devel] [Xen-devel] More virtio users
From: "Caitlin Bestler" <caitlinb@xxxxxxxxxxxx>
Date: Thu, 14 Jun 2007 12:41:43 -0700
Cc: kvm-devel@xxxxxxxxxxxxxxxxxxxxx, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, virtualization <virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 14 Jun 2007 12:40:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200706130154.27513.arnd@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aceunm4jitGiXl4XRiqj2I2Cw3sWgQAHRlSQ
Thread-topic: [kvm-devel] [Xen-devel] More virtio users
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote:
> On Wednesday 13 June 2007, Caitlin Bestler wrote:
>> 
>>> It can be done, but you'd also need a passthrough for the IOMMU in
>>> that case, and you get a potential security hole: if a malicious
>>> guest is smart enough to figure out IOMMU mappings from the device
>>> to memory owned by the host. 
>>> 
>> If it is possible for a malicious guess to use the IOMMU to access
>> memory that was not assigned to it then either the Hypervisor is not
>> really a Hypervisor or the IOMMU is not really an IOMMU.
> 
> Unfortunately, most IOMMU implementations are not really
> IOMMUs then, I guess ;-). To be safe, every PCI device needs
> to have its own tagged DMA transfers, which essentially boils
> down to having each device behind a separate PCI host bridge,
> and that's not very likely to be done on PC style hardware.
> 
> Admittedly, I haven't seen many IOMMU implementations, but
> the one I'm most familiar with (the one on the Cell Broadband
> Engine) can only assign a local device on the north bridge to
> one guest in a secure way, but an entire PCI or PCIe host is
> treated as a single device when seen from the IOMMU, so when
> one PCIe device has a mapping to guest A, guest B can use
> MMIO access to program another device on the same host to do
> DMA into the buffer provided by guest A.
> 
Why not simply adopt the policy that if the IOMMU does not meet
the security requirements of the Hypervisor then it is not an
IOMMU as far as the Hypervisor is concerned?

More specificially, the Hypervisor should enable direct access
by a Guest to a device *only* if an IOMMU functionality exists
to allow the Hypervisor to create a virtual IO memory map that
controls *precisiley* which pages the device is allowed to
access for that guest.

If such functionality is not available then the Guest MUST NOT
access the device directly, and a frontend/backend solution 
must be used instead.

Basically, there are no security problems using an IOMMU, because
if there is a security problem it is not an IOMMU.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel