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

On Thursday 14 June 2007, Caitlin Bestler wrote:
> 
> 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.

We shouldn't redefine standard terms, IOMMUs have existed for a
long time on systems that do not run hypervisors, and it's not
often clear if they have a security problem or not.

In case of the Cell Broadband Engine I already mentioned, there
is an IOMMU integrated on the CPU which has all the necessary
features needed for secure operation. However, whether those
are effective depends on the type of I/O device you connect
to it.

With the "axon" bridge chip, it is by default insecure and
we should not allow access from any guest, while the "spider"
bridge has some devices (e.g. USB and network) that are
guaranteed to be safe when set up correctly, and other devices
that are not.

I agree that we shouldn't allow guest to access devices if
that is dangerous, but that doesn't mean that the IOMMU
magically is something else than an IOMMU.

        Arnd <><

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