Muli Ben-Yehuda wrote:
On Mon, Dec 07, 2009 at 11:38:52AM -0600, Anthony Liguori wrote:

I'm skeptical that VT-d in its current form provides protection
against a malicious guest.  The first problem is interrupt delivery.
I don't think any hypervisor has really put much thought into
mitigating interrupt storms as a DoS.  I think there are a number of
nasty things that can be done here.

Seems to me that detecting an interrupt storm and shutting the
offending domain and device off is fairly easy for MSI and MSI-X
interrupts, and not-interesting for legacy INTx interrupts. I don't
know that any hypervisor actually implements it, though.

Even if you assume that there aren't flaws in VT-d wrt malicious
guests, we have generations of hardware that have not been designed
to be robust against malicious operating systems.  There are almost
certainly untold numbers of exploitable hardware bugs that can be
used to do all sorts of terrible things to the physical system.

To the device? Undoubtedly. To the host? I'm not so sure.

But in the context of SR-IOV, impacting the device may result in disrupting (and potentially exploiting) other domains.

And I'm waiting for the "malicious guest sets server on fire" CVE :-) I'm convinced there will be at least one.

VT-d protects against DMA access, but there's still plenty of things
a malicious PCI device can do to harm the physical system.  I'm sure
you could easily program a PCI device to flood the bus which
effectively mounts a DoS against other domains.

But is there any way the device could do this and also evade detection
of evade being taken off-line by the host, after first killing its
controlling VM?

Thing is, the bus is shared by the host too. So if the guest is able to bring all IO devices on the system to a halt, an administrator certainly couldn't connect remotely to take corrective action.

I think all of this could potentially be detected and handled but I assume there's years of research here before that's a reality.

There is no mechanism to arbitrate this today.  It's really a
dramatically different model from a security perspective.

I think we need to differentiate between assigning full (legacy)
devices, and assigning an SRIOV VF. In the latter---more
interesting---case, the host remains in control of the overall device,
so shutting off a mis-behaving VF should be simple.

SR-IOV is worse IMHO because now there are multiple guests that can be impacted by a hardware exploit.

Regards,

Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to