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
