Re: A few KVM security questions

[Avi Kivity <avi@redhat.com>]

On 12/07/2009 07:15 PM, Joanna Rutkowska wrote:
>>>
>>> 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.
>    

AFAIK VT-d is only supported in Xen for fully virtualized guests.  Maybe 
it changed while I wasn't watching, though.

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

It can use read() and write() (and shared memory) to communicate, just 
like Xen stub domains.

It's a lot of surgery, but it can be done.

-- 
error compiling committee.c: too many arguments to function