Re: A few KVM security questions

[Avi Kivity <avi@redhat.com>]

On 12/07/2009 03:30 PM, Joanna Rutkowska wrote:
> Avi Kivity wrote:
>
>    
>>> 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.
>>
>>      
> Can I run a regular Linux as PV-guest? Specifically, can I get rid of
> qemu totally, assuming I have only PV guests?
>
>    

No.  Paravirtualization just augments the standard hardware interface, 
it doesn't replace it as in Xen.

> E.g. do you have PV network and disk frontends (PV drivers), that I
> could use on guests and that do not use qemu at all?
>    

We do have PV network and disk frontends, but the backends (devices) are 
still in qemu.

>> 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.
>>      
> But bridging would still require to have some networking support (+net
> backends) on the host (sure, without any real NIC driver, but still),
> correct?
>    

If you were willing to hack a bit, you can use any IPC to pass the 
packets instead of the networking stack (for example, shared memory + 
eventfd for signalling).

>>> 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.
>>
>>      
> Does this stub driver sets DMA protections, so that the device in
> question cannot access any host memory?
>
> That is important, because once you assigned a device to some VM, we
> should assume the VM might have somehow compromised the device, e.g.
> reflashed the firmware of the NIC, perhaps. So, it's important to be
> able to protect the hypervisor from such devices.
>    

kvm places assigned devices in an iommu protection domain so it cannot 
attack the host.  Once the guest stops using the device, we reset it.  
If the guest is able to upload a malicious, persistent payload to the 
device, then when the device is reused whoever uses it will be 
vulnerable (whether a new guest or the host).

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