Avi Kivity wrote: > 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. >
Negative. VT-d can be used to contain PV DomUs as well. We actually verified it. >>>> 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. > Well, but the read() and write() syscalls, on a system like Linux, it's a gate to *lots* of code. These are very powerful system calls. > It's a lot of surgery, but it can be done. > And then you have the code with whom this qemu communicates (e.g. the network stack). You said we could somehow use IPC to delegate it to some VM (that would have VT-d assigned NIC). But then this VM would need to use qemu again (of course this time not for net emulation). Looks non-trivial. joanna.
signature.asc
Description: OpenPGP digital signature
