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.
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.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
