Anthony Liguori wrote: > Avi Kivity wrote: >> No. Paravirtualization just augments the standard hardware interface, >> it doesn't replace it as in Xen. > > NB, unlike Xen, we can (and do) run qemu as non-root. Things like > RHEV-H and oVirt constrain the qemu process with SELinux. > On Xen you can get rid of the qemu entirely, if you run only PV domains. > 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. 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. Also, SELinux seems to me like a step into the wrong direction. It not only adds complexity to the already-too-complex kernel, but requires complex configuration. See e.g. this paper[1] for a nice example of how to escape SE-sandboxed qemu on FC8 due to SELinux policy misconfiguration. When some people tried to add SELinux-like-thing to Xen hypervisor, it only resulted in an exploitable heap overflow in Xen [2]. [1] http://invisiblethingslab.com/resources/misc08/xenfb-adventures-10.pdf [2] http://invisiblethingslab.com/resources/bh08/part2-full.pdf joanna.
Attachment:
signature.asc
Description: OpenPGP digital signature
