Re: A few KVM security questions

[Joanna Rutkowska <joanna@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 2748 bytes --]

Anthony Liguori wrote:
> Joanna Rutkowska wrote:
>> Avi Kivity wrote:
>>  
>>> On 12/07/2009 07:09 PM, Joanna Rutkowska wrote:
>>>    
>>>>> Also, you can use qemu to provide the backends to a Xen PV guest
>>>>> (see -M
>>>>> xenpv).  The effect is that you are moving that privileged code
>>>>> from the
>>>>> kernel (netback/blkback) to userspace (qemu -M xenpv).
>>>>>
>>>>> In general, KVM tends to keep code in userspace unless absolutely
>>>>> necessary.  That's a fundamental difference from Xen which tends to do
>>>>> the opposite.
>>>>>
>>>>>              
>>>> But the difference is that in case of Xen one can *easily* move the
>>>> backends to small unprivileged VMs. In that case it doesn't matter the
>>>> code is in kernel mode, it's still only in an unprivileged domain.
>>>>
>>>>          
>>> They're not really unprivileged, one can easily program the dma
>>> controller of their assigned pci card to read and write arbitrary host
>>> memory.
>>>
>>>     
>>
>> That's not true if you use VT-d.
>>   
> 
> 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.
> 

Intel VT-d v1 doesn't support interrupt remapping, so I'm sure you're
right here. But DoS attack is a different thing then a system subversion
(think malware) attack. Of course which one you fear more would depend
on your threat model.

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

Perhaps, although so far nobody presented a software-only VT-d escape
attack. I think it's reasonable to assume some maniacs would discover a
one or two in the coming years. Still, probably order of magnitude less
likely than a Linux kernel overflow.

> 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.  There is no mechanism to arbitrate
> this today.  It's really a dramatically different model from a security
> perspective.
> 

Agree, there are lots of DoS possibilities. It's just that for me,
personally, they are not in the threat model.

joanna.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]