-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sun, Jul 30, 2017 at 01:28:17PM -0700, sptank...@gmail.com wrote: > I've read with some interest the discussion of Xen security downsides and > the Qubes architecture requirements for hypervisors. With the upcoming move > to HVM (ditching PV), how might this impact the viability of KVM as a > hypervisor for Qubes? > > Specifically, some of the main reasoning for preferring Xen to KVM were: > - Xen hypervisor is very small compared to Linux kernel > - Xen allows to move most of the “world-facing” code out of Dom0, including > the I/O emulator, networking code and many drivers > - Xen supports driver domains, KVM doesn't > - Xen has better isolation for the I/O emulator process, via two mechanisms: > (1) PV domains just don't use it, so no IOemu at all > (2) for each HVM, per-domain virtualized-isolated slices of IOemu > > cf. > https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf > > As I understand it, driver domains and IOemu domains are related, but > separate things. Part of Xen's IOemu-domain advantage seems to be > disappearing with the move to HVM. (Is this correct or mistaken?) > > It seems one major residing problem with KVM is the Linux kernel (which is > large and vulnerable). A port of KVM to a thinner base layer would obviate > those issues.
Yes, that's right. > In particular, the development of the Redox microkernel seems > interesting because the community is energetic and it's written in the hot > new language, Rust. It's far too early to tell whether it will be feasible, > but an eventual port of KVM to Redox might be a good candidate for > replacing Xen in Qubes (you get a smaller TCB + the benefits of Rust over > C). At clownishly rough estimations, Redox+KVM would be (20 to 30k) + (40 > to 100k) = 60 to 130k LOC, which is significantly smaller than Xen > (240-300k). > > Of course other microkernels are also of interest (there's been discussion > on this list of Muen SK) and hopefully tooling and modularization for KVM > porting could be reusable over different microkernels. > > Open question: replacing Linux with e.g. Redox, what KVM downsides (vs Xen, > for Qubes) would remain? > > A couple specific questions that I don't know the answer to: > - Where does KVM stand today on non-privileged driver domains? Last time I've checked it wasn't possible to have for example network connection between two domains without either heavy host kernel usage (including ethernet parsing, switching etc), or significant performance impact (at least two memory copy of all the data). Or disk backend outside of the one qemu instance. But that was some time ago, maybe something have changed? > - Can KVM isolate IOemu into per-domain virtualized-isolated slices? > > Recent research such as DeHype and HyperLock have enabled splitting KVM > into per-VM slices, but both seem to leave QEMU untouched and monolithic. > (Not good.) See > https://www.internetsociety.org/sites/default/files/ndss2017_02A-4_Shi_paper.pdf > > (p3, fig 1) As long as compromising such monolithic QEMU does not ease compromising other domains (like other QEMU processes, host kernel etc), it shouldn't be a big problem from security POV. On the other hand, if selected device emulators (and/or virtio backends) could live in different qemu instances (or even not qemu), in different domains, that would help with the first point. > Additionally here is my feeble attempt at answering the "Eight Questions" > for KVM: > > 1) Has HVMs and some PV support. Needs better PV support. > 2) No, unmodified usermode binaries. > 3) Runs unmodified drivers. Also special paravirt drivers. > 4) Yes, supports VT-d. Untrusted driver domains? Dunno, maybe not. > 5) S3 sleep? Yes. > 6) Yes, works on multiple chipsets. > 7) Similar to Xen on most benchmarks? > 8) Other special features...? Dunno. Eliminates cooperative covert channels > between VMs? Dunno. > > The 8 Questions: > https://www.qubes-os.org/doc/user-faq/#why-does-qubes-use-xen-instead-of-kvm-or-some-other-hypervisor > > Some other links of reference: > > https://groups.google.com/forum/#!topic/qubes-devel/uVYowLAXd0M > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt > - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJZflEhAAoJENuP0xzK19csHpsH/1vJWP00I+cLrpJN4UvFotec LUwrb+4kweodbqVau2sP06vE8c0swQ8I22PFNWB+5XUSd35hHLBkf5jo4VBocCCH HNpZ4SuNm/58OqGz0LFs2PUq0HRMgufVTVKOSepFqr4SICvrhpLtoUP/GTp4IWtI xZZankWPxd08VHbIn433f5rP9aTHHzDbL8uc+Udi1O3m8IR9dWBZWIMOtBMhB0/N 7ot/EjLSfMlRc0iKxwbBg20dlvJ4Yz+E64EIcafFdrNCeVWbhre3rS99FoieoURZ 3OpcIu9sO4bLsgTT+xTGe46pg8VumzSb+IjO52ez+8Xjv2tX4QYBvYcwuvcLDrw= =9Esi -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170730213528.GI1095%40mail-itl. For more options, visit https://groups.google.com/d/optout.
