On 12/07/2009 07:15 PM, Joanna Rutkowska wrote:
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.
AFAIK VT-d is only supported in Xen for fully virtualized guests. Maybe
it changed while I wasn't watching, though.
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...
It can use read() and write() (and shared memory) to communicate, just
like Xen stub domains.
It's a lot of surgery, but it can be done.
--
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
