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

["Caitlin Bestler" <caitlinb@xxxxxxxxxxxx>]

Arnd Bergmann wrote:
> 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 <><

It's not making up a term, it's citing a specific standard.
I believe that only the degree of isolation provided by the
PCI-SIG SR IOV definition of an IOMMU, or something equivalent,
provides sufficient isolation to allow a Hypervisor to directly
connect a guest and a device.

If a guest can be "clever" (and/or clumbsy) and access memory
that was not assigned to it by the Hypervisor through the use
of a device then the guest cannot be allowed direct access to
the device.

Are you suggesting that the Hypervisor should allow guests
to access devices via limited IOMMUs that cannot guarantee
security and that these limitations should just be documented?

Whatever it is called elsewhere, an "IOMMU" that cannot guarantee
that it will only allow authorized memory access on request of
a directly connected guest is not relevant to discussions of
virtualization.


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