-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, Dec 05, 2019 at 04:27:33PM -0800, John Smiley wrote: > I've read various things that hint at some major changes coming to Qubes OS > and so I have been holding off continuing to invest my time in diving deep > into the current implementation. In particular, I've seen indications that > Qubes is migrating away from Xen and toward KVM.
This is very much not true. We are considering adding support for KVM, but Xen isn't going away anytime soon. > Xen seems to be "mostly > dead" as Billy Crystal would say and many services either already have or > are well on their way to replacing it with KVM. Well, yes and no, mostly no. There are some services that are starting to use KVM, but the same applies to Xen. I think you mostly have Amazon in mind, which indeed started to have some VMs on KVM. On the other hand, this year their contributions to open source Xen have very much intensified, including development of many new features. Besides that, Xen is getting popularity in automotive sector, and there are ongoing efforts for safety certification. Yet another thing that is totally unrealistic with KVM architecture. You may want to look at Xen Summit recap: https://xenproject.org/2019/07/29/xen-project-developer-and-design-summit-recap/ > There also seems to be > movement toward more lightweight solutions for isolating processes than > virtual machines, as seen in Subgraph/Citadel/Oz (which oddly have not seen > much attention in recent years if GitHub is anything to go by). Well, people are using containers for a long time already. While indeed it is much more lightweight, this approach have also severe limits - everything running on the same (huge, monolithic) kernel. Leaving alone much bigger attack surface of all the syscalls (which you can slightly mitigate with seccomp and similar techniques), this makes it impossible to isolate kernel components from each other. Including drivers, network stack etc. > I'm sure I'm not alone when I say I would like to hear from the Qubes > developers what the roadmap looks like in this regard. Some of us would > probably be more inclined to devote our time to assisting you if we knew > such projects were in the works. The current plan for major features of Qubes OS 4.1 is: - experimental GUI VM and Audio VM (very limited and not yet ready for daily usage) - new qrexec policy format and significant qrexec performance improvements - major improvement for UEFI compatibility (grub2-efi is back, some changes in Xen to make it more uniform with Linux) - as usual, updated templates and dom0 (but still Fedora) You can also see draft release notes: https://github.com/QubesOS/qubes-doc/pull/828/files I'd say the above is 80-90% done. There is a possibility the first release candidate will be already this month. In the meantime we're also working on a reliable GPU passthrough with focus on Intel, without sacrificing security much (specifically, without running unsandboxed qemu), but it's not going to be part of R4.1 yet. Having that, and more tested and improved GUI VM integration would allow to make it default and greatly reduce size of dom0. With such reduced dom0, we can consider another distribution there. It hasn't been decided on a specific one yet, but I'm strongly considering Yocto/OpenEmbedded - for its ability to build small system. Maybe even small enough to fit in RAM, which would allow running dom0 disk-less, opening a path to many cool features like storage domain. But it would also allow easier code sharing with OpenXT project. Anyway, at this point, user would not directly interact with dom0, so it will be very much transparent (i.e. even if that would be Debian - which is another option - you won't have a chance to call apt-get there). What user will interact with, is a GUI VM, which would be much more flexible in distribution choice (basically - whatever template we currently support). But also, with GUI VM separated from all-powerful dom0, we can consider some options for video acceleration access for selected VMs. There are various paths here to be explored, with different hardware requirements, and different security properties. But that's for late 2020 at the earliest. - -- 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----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl3pvCsACgkQ24/THMrX 1yxVKggAgKOBn/KcV+aZELbKDRHEXDpIqZXaUBe0Xr2kDeu0QtprBG8HgCLax2GJ 4szkmBXa7LD7NHMb6Ee8wzTp/C3VTF/xqfpvXrveOQsgzNLyoitxWzDhOrSKABQq DHFUrNNdCHqKpn6WGcqC2qEfdHM1rR5UdzzJIMyXIiSIYfJ6PdsJoW69DWw8iLeG 0U3/hq58bBR7j0Ymlw5Y/7liGZSD6Fj44CC21q/M1gq3g3rtgPbgN5r3mhTAAlNL boQUmkkfy1GJ4Kxo/sYhpauLRxWnvQFhdWLfRyka+3W91nqK3qVUuALeaUaDcTQ3 jk0/tT1a2OkpKviWd2qv7dUIpjU4Yg== =D6Lu -----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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20191206022547.GH1122%40mail-itl.
