Re: A few KVM security questions

[Anthony Liguori <anthony@codemonkey.ws>]

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