Re: A few KVM security questions

[Joanna Rutkowska <joanna@invisiblethingslab.com>]

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

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.

>> Sandboxing a process in a monolithic OS, like Linux, is generally
>> considered unfeasible, for anything more complex than a hello world
>> program. The process<->  kernel interface seem to be just too fat. See
>> e.g. the recent Linux kernel overflows by Spender.
>>    
> 
> What about seccomp?  You can easily simplify qemu to just a bunch of
> calculations served over a pipe.
> 
But the qemu must somehow communicate with the external world too, no?
You said you provide e.g. net backend via the qemu process...

joanna.


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