Re: A few KVM security questions

[Avi Kivity <avi@redhat.com>]

On 12/07/2009 07:33 PM, Joanna Rutkowska wrote:
>
>> AFAIK VT-d is only supported in Xen for fully virtualized guests.  Maybe
>> it changed while I wasn't watching, though.
>>
>>      
> Negative. VT-d can be used to contain PV DomUs as well. We actually
> verified it.
>
>    

Ah, good for them.

>> It can use read() and write() (and shared memory) to communicate, just
>> like Xen stub domains.
>>
>>      
> Well, but the read() and write() syscalls, on a system like Linux, it's
> a gate to *lots* of code. These are very powerful system calls.
>    

But you control all the file descriptors.  A minimal system would just 
consist of a pair of eventfd fds for signalling and shared memory (the 
Xen equivalent is event channels and grant tables).

>> It's a lot of surgery, but it can be done.
>>
>>      
> And then you have the code with whom this qemu communicates (e.g. the
> network stack). You said we could somehow use IPC to delegate it to some
> VM (that would have VT-d assigned NIC). But then this VM would need to
> use qemu again (of course this time not for net emulation). Looks
> non-trivial.
>    

It doesn't really need to be a VM.  Once the seccomp constrained qemu 
processes the guest actions, the result is a fairly simple event stream.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.