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

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

[Arnd Bergmann]

On Sunday 10 June 2007, Avi Kivity wrote:
> > - PCI (or your favorite HW bus) passthrough, for your favorite oddball
> >   device (e.g., crypto-accelerators).
> >   
> Won't all high-bandwidth traffic be through dma, bypassing virtio?

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.

	Arnd <><

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

[Caitlin Bestler]

virtualization-bounces@lists.linux-foundation.org wrote:
> On Sunday 10 June 2007, Avi Kivity wrote:
>>> - PCI (or your favorite HW bus) passthrough, for your favorite
>>> oddball   device (e.g., crypto-accelerators).
>>> 
>> Won't all high-bandwidth traffic be through dma, bypassing virtio?
> 
> 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.

The only real difference between enabling DMA and providing
IO buffers are the durations. The security implications are
identical.

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

[Arnd Bergmann]

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.

	Arnd <><

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

[Muli Ben-Yehuda]

On Wed, Jun 13, 2007 at 01:54:26AM +0200, Arnd Bergmann 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 ;-).

Nowdays when people say 'IOMMU', they really mean 'isolation-capable
IOMMU', i.e., one that provides more than a single address space. In
that sense, most IOMMU implementations really aren't (isolation
capable) IOMMUs.

> 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.

IBM, Intel and AMD all have x86 IOMMUs that provide some degree of
isolation between different devices (per bus or per device function),
where different BDF's have different IO translation tabels.

> 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.

That's not an isolation capable IOMMU then.

Cheers,
Muli

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

[Caitlin Bestler]

xen-devel-bounces@lists.xensource.com 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.

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

[Arnd Bergmann]

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 <><

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

[Caitlin Bestler]

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.