Re: A few KVM security questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux