Qubes 3.2 released


Excerpting information about the new 3.2 “USB passthrough” feature from the announcement blog post:

[…] In Qubes 3.2, we’re also introducing USB passthrough, which allows one to assign individual USB devices, such as cameras, Bitcoin hardware wallets, and various FTDI devices, to AppVMs. This means that it’s now possible to use Skype and other video conferencing software on Qubes! Qubes has supported the sandboxing of USB devices since the very beginning (2010), but the catch has always been that all the USB devices connected to the same USB controller had to be assigned to the same VM. This limitation was due to the underlying hardware architecture (specifically, PCIe and VT-d technologies). We can now get around this limitation by using software backends. The price we pay for this, however, is increased attack surface on the backend, which is important in the event that several USB devices of different security contexts are connected to a single controller. Sadly, on laptops this is almost always the case. Another potential security problem is that USB virtualization does not prevent a potentially malicious USB device from attacking the VM to which it is connected. These problems are not inherent to Qubes OS. In fact, they pose an even greater threat to traditional, monolithic operating systems. In the case of Qubes, it has at least been possible to isolate all USB devices from the user’s AppVMs. The new USB passthrough feature gives the user more fine-grained control over the management of USB devices while still maintaining this isolation. Nonetheless, it’s very important for users to realize that there are no “automagical” solutions to malicious USB problems. Users should plan their compartmentalization with this in mind. We should also mention that Qubes has long supported the secure virtualization of a certain class of USB devices, specifically mass storage devices (such as flash drives and external hard drives) and, more recently, USB mice. Please note that it is always preferable to use these special, security-optimized protocols when available rather than generic USB passthrough. […]


Qubes OS 3.1 rc1 released, with UEFI support

New features since 3.0:
 * Management Stack based of Salt Stack in dom0
 * Out of the box Whonix setup
 * UEFI support
 * LIVE edition (still alpha, not part of R3.1-rc1)
 * Updated GPU drivers in dom0
 * Colorful window application icons (instead of just colorful lock icon)
 * PV Grub support (documentation)
 * Out of the box USB VM setup, including handling USB mouse
 * Xen upgraded to 4.6, for better hardware support (especially Skylake platform)
 * Improve updates proxy flexibility – especially repositories served over HTTPS





Purism adopts Qubes OS

Purism has announced a partnership with Qubes OS, users will be able to order Qubes OS preinstalled on the Librem 13.

Excerpted quotes from press release:

“We are pleased to partner with the Purism team both in offering a certified Qubes OS laptop today, and in the future improving the functionality and security of Purism laptops to ensure that users can have the best of freedom, security and privacy in one convenient package,” said Joanna Rutkowska, well-known security researcher and founder of the Qubes OS project.

“We are ecstatic about the partnership between Purism and Qubes so we can bring together our goals of privacy, security and freedom in hardware with the best approach in software security. This union represents the ideal approach to protecting users by default, without sacrificing convenience or usability,” said Todd Weaver, CEO of Purism. “Qubes OS is a natural fit with the Purism Librem laptops in both functionality and ideology.”

Full press release:


I was originally wondering why not use Qubes instead of PureOS in the first place, so I’m happy with their use of Qubes for OS solution.

I’m unclear about status of PureOS, is it mothballed or is it another OS option for Librem? Given use of Qubes, what does this say about future hardware architecture choices by Purism? AFAICT, Qubes is an Intel/AMD-centric OS, will PureOS still be used on ARM-based tablets/smartphones? Will Qubes have any ARM port?


Critical bug in Xen hypervisor

Wow, Joanna of ITL says “IMHO this is the worst bug affecting Xen, ever.”

Excerpt from Qubes Security Bulletin #22:

Critical Xen bug in PV memory virtualization code (XSA 148)

The Xen Security Team has announced a critical security bug (XSA 148) in the hypervisor code handling memory virtualization for the PV VMs [1]:

| The code to validate level 2 page table entries is bypassed when
| certain conditions are satisfied.  This means that a PV guest can
| create writeable mappings using super page mappings.
| Such writeable mappings can violate Xen intended invariants for pages
| which Xen is supposed to keep read-only.

The above is a political way of stating the bug is a very critical one. Probably the worst we have seen affecting the Xen hypervisor, ever. Sadly.

Full advisory:



QubesOS 3.0 released

Qubes released 3.0 today! Joanna Rutkowska posted a blog entry on it today. This release is dedicated to the memory of Caspar Bowden, a pioneer in privacy. Excerting Joanna’s anouncement of some of 3.0’s features:

Qubes is now based on what we call Hypervisor Abstraction Layer (HAL), which decouples Qubes logic from the underlying hypervisor. This will allow us to easily switch the underlying hypervisors in the near future, perhaps even during the installation time, depending on the user needs (think tradeoffs between hardware compatibility and performance vs. security properties desired, such as e.g. reduction of covert channels between VMs, which might be of importance to some users). More philosophically-wise, this is a nice manifestation of how Qubes OS is really “not yet another virtualization system”, but rather: a user of a virtualization system (such as Xen).

We upgraded from Xen 4.1 to Xen 4.4 (now that was really easy thanks to HAL), which allowed for: 1) better hardware compatibility (e.g. UEFI coming soon in 3.1), 2) better performance (e.g. via Xen’s libvchan that replaced our vchan). Also, new Qubes qrexec framework that has optimized performance for inter-VM services.

We introduced officially supported Debian templates.

We integrated Whonix templates, which optimize Tor workflows for Qubes.

The work on 3.1 is underway, with some features planned, including UEFI support, Live USV edition, and a management/pre-configuration stack.

Full announcement:

EFI support ticket:


Qubes OS 3.0-rc3 released

3.0 also includes a LiveUSB build.

No specifics of bugfixes, as they’re on a regular update schedule these days.





Qubes 3.0-RC alpha of LiveUSB release

Joanna Rutkowska of Invisible Things Lab posted a message to the qubes-users mailing list today, announcing a new Live USB image format of Qubes OS.

“We have built and uploaded the first ever working Qubes Live USB image! 🙂 It’s based on the recently released 3.0-rc2 release. Now you should be able to run and try Qubes OS of any laptop without needing to install it anywhere!”

Note that it currently does not work with UEFI:

“We have faced several challenges when making this Live USB edition of Qubes OS, which traditional Linux distro don’t need to bother with:
1. We needed to ensure Xen is properly started when booting the stick. In fact we still don’t support UEFI boot for the sitck for this reason, even though the Fedora liveusb creator we used does support it. Only legacy boot for this version, sorry.
Current limitations
7. UEFI boot doesn’t work, and if you try booting it via UEFI Xen will not be started, rendering the whole experiment unusable.”

Read the full announcement here: