Re: A few KVM security questions

[Avi Kivity <avi@redhat.com>]

On 12/07/2009 03:05 PM, Joanna Rutkowska wrote:
> Hello,
>
> I have the following questions regarding the KVM architecture. I looked
> at the slides available at linux-kvm.org, but didn't find definitive
> answers. I'm also interested to learn if given feature is or is not
> planned for the near future.
>
> The questions follow:
>
> 1) Do you have any support for para-virtualized VMs?

Yes, for example, we support paravirtualized timers and mmu for Linux.  
These are fairly minimal compared to Xen's pv domains.

> In particular, is
> it possible to move the qemu from the host to one of the VMs? Perhaps to
> have a separate copy of qemu for each VM? (ala Xen's stub-domains)
>    

It should be fairly easy to place qemu in a guest.  You would leave a 
simple program on the host to communicate with kvm and pass any data 
written by the guest to qemu running in another guest, and feed any 
replies back to the guest.

It should also be possible to constrain qemu using SECCOMP.

None of this has been attempted to my knowledge.

> 2) Is it possible to have driver domains in KVM? E.g. I would like to
> assign my NIC to one VM (a "network domain") and then I would like other
> domains to use this network domain for networking. In case of Xen, this
> is done by moving the network backend (which is not qemu BTW) into the
> network domain, and configuring the network frontends in other VMs to
> talk to this network domain's backend, rather then to Dom0's backend (in
> fact you can get rid of all the networking in Dom0).
>    

Should be doable by assigning the NIC to a driver domain and bridging it 
to a virtio driver; then have the driver domain's virtio device talk to 
the ordinary guests.

> 3) Do you have any support for TXT-based trusted boot? I guess you
> indirectly have via tboot. However, how do you deal with VT-d
> protections? The tboot.gz should normally DMA-protect memory before
> handing execution over to Linux kernel. But then you need to allow your
> drivers to work. Do you unprotect all the memory for DMA, or do you have
> some support for selectively unprotect only those regions of memory
> which are needed by (some) drivers? If the latter, how do you determine
> which memory should be DMA-unprotected?
>    

I know nothing about tboot.

> 4) Do you have some method of excluding particular PCI devices from
> being initialized by your host Linux? E.g. those devices that are later
> to be assigned to some VMs (via VT-d passthrough)?
>
>    

Yes, there is a stub driver that does this.


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