Finally, after years of work, we’re releasing the first release candidate for Qubes 4.0!

Next Generation Qubes Core Stack for better integration

No doubt this release marks a major milestone in Qubes OS development. The single most import undertaking which sets this release apart, is the complete rewrite of the Qubes Core Stack. We have a separate set of posts detailing the changes (Why/What/How), and the first post is planned to be released in the coming 2 weeks.

This new Core Stack allows to easily extend the Qubes Architecture in new directions, allowing us to finally build (in a clean way) lots of things we’ve wanted for years, but which would have been too complex to build on the “old” Qubes infrastructure. The new Qubes Admin API, which we introduced in a recent post, is a prime example of one such feature. (Technically speaking, we’ve neatly put the Admin API at the heart of the new Qubes Core Stack so that it really is part of the Core Stack, not merely an “application” built on top of it.)

There are many more benefits that the new Core Stack brings besides the Admin API. Just to name a few that might be most visible to the user or admin:

  • Simpler to customize and more flexible Disposable VMs,
  • More flexible and expressive (qrexec) policy definitions,
  • Flexible VM volume manager (easy to keep VMs on external drives, or in memory-only),

… and many more! The new Core Stack also brings lots of simplifications for developers of Qubes-specific apps and services. Again, we plan to publish posts about all these cool new features in the coming weeks and months.

One last important comment is that all the work we have done in this area has been Xen-agnostic, aligned with our long-stated goal to make Qubes easily portable between different VMMs (hypervisors) and even non-VM-based systems, such as container-based ones.

Fully virtualized VMs for better isolation

Another important change in this release (this time Xen-specific) is that we have ditched para-virtualized mode and embraced fully-virtualized mode for Qubes VMs. The reason for this move has been entirely security-related, as explained here and here.

Originally, we planned to utilize the PVH mode of virtualization, which combines the benefits of processor virtualization technologies (VT-x and EPT), allowing for simpler code in the hypervisor, thus improving security, with paravirtualized drivers for better performance and improved security due to simplified interfaces to virtualized devices. Even though we have long been using isolated stub domains to keep device I/O emulators outside of the TCB, these stub domains themselves run in PV mode, which we are now moving away from.

Sadly, due to the Linux kernel still not fully supporting this PVH mode (specifically problems with booting the kernels in this mode), we decided to go with the HVM-based VMs for this rc1 release. We plan to switch to full PVH either in the later rc-releases, or in 4.1, depending on the progress of PVH support in the Linux kernel.

Also, as an additional last-minute issue, we discovered that PCI pass-through does not work that well on some systems when using HVM virtualization. Typically this affects USB VMs and only on some systems. Nevertheless, as a precaution, in the default installation we decided to switch the mode of virtualization for these VMs back to PV mode. (The new Core Stack allows one to do this with the flip of a switchproperty :). Here our rationale is that it’s still much better to have PV-based isolation for USB VMs rather than not having USB controllers isolated at all! Again, we anticipate this will be resolved in the upcoming rc-releases.

New approach to UX/UI for better integration

In Qubes 4.0 we also decided to redesign the User Experience (UX) a little bit. Aligned with our long-term vision to hide as much of the Qubes internals from the casual user as practically viable, we made a bold move and… removed the Qubes Manager altogether!

Instead, we believe it makes more sense to utilize as much of the infrastructure already built by professional UX designers as possible. Consequently, most of the Qubes persistent configuration (creation of new VMs, changing their settings as well as the global ones) is accessible through the standard application menu aka “Start Menu”. In addition, we wrote two tiny widgets, which should work with most desktop environments compatible with Qubes (currently this list includes the default Xfce4, the once-default KDE, the community-maintained i3, and awesome). These widgets are used to show live info about the running system state, such as which VMs are currently running, their memory usage, as well as which devices are available to connect to different VMs (and yes, now it is possible to connect USB devices using the GUI, a long requested feature by many of our users).

Advanced Qubes users will surely appreciate, on the other hand, the much more flexible and powerful qvm-* tools, such as the completely rewritten qvm-ls and qvm-prefs, to name just two (again, more on them in the upcoming posts).

Better compatibility and all the rest

Besides the above, there have been lots of other improvements and bug fixes compared to the 3.2 release. We list most of them in the release notes.

Perhaps one worth singling out here, in the context of hardware compatibility, is the upgrade of the default dom0 distribution to Fedora 25. (Before we decompose dom0 into separate GUI and Admin VMs, which we plan to do in 4.1, the dom0 distribution determines how well the GPU is supported.)


Qubes 4.0 is a significant milestone on our roadmap to implement a reasonably secure desktop/client OS based on the “Security by Compartmentalization” principle (using “Explicit Partitioning Model”, in contrast to the recently popular “Sandboxing Model”).

This is the first release candidate of a largely rewritten complex system, and no doubt early adopters will discover some rough edges here and there. Despite our increasingly sophisticated automatic testing infrastructure, this is simply unavoidable. Consequently, if you want to use Qubes for production, stick to Qubes 3.2 until we release the stable version of Qubes 4.0.

But if you would like to start learning and experimenting with the advanced new features that 4.0 brings, such as the Admin API, or would like to help us reach a stable 4.0 more quickly, or you’re just curious, or want to show off to your friends what a bleeding edge system you have, then please do so and go straight to the [download page]!

On behalf of the whole Qubes OS Core Team,