-----BEGIN PGP SIGNED MESSAGE-----
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:
> 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
> 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
- new qrexec policy format and significant qrexec performance
- 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:
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
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.
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-----
-----END PGP SIGNATURE-----