New in version 3.0
October 2nd, 2015
- 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.
- And finally: we integrated Whonix templates, which optimize Tor workflows for Qubes
New in version 3.0 RC1 (April 26th, 2015)
- It implements the new hypervisor-abstracted architecture (which we call: HAL), and introduces a load of new features: Xen 4.4, new qrexec, and brings lots of new VM templates with full Qubes integration: Debian 7 and 8, Whonix 9, and many more.
- It also provides important modifications and improvements to our build system.
New in version 2 RC2 (August 7th, 2014)
- After Qubes rc1 release a few months ago we have been hit by a number of problems related to unreliable VM start-ups. The most prevalent problem has been traced down to an upstream bug in systemd, which just happened to be manifesting on Qubes OS due to specific conditions imposed by our startup scripts.
- Actually, it has not been the first time when some things related to VM bootup or initialization didn't work quite well on Qubes, a side effect of heavy optimizations and stripping down we do in order to make the VMs as light weight as possible. E.g. we don't start most of the Desktop Environment which otherwise is assumed to be running by various desktop-related applications and services. In most cases these are really NOTOURBUG kind of problems, yet we just happen to be unlucky they manifest on Qubes. We do need more help from the community with testing, debugging and patching such NOTOURBUG problems in the upstream. The more people use Qubes OS, the higher the chances such problems will be addressed much quicker. Ideally, in the future, we could partner with a Linux distro that would include Qubes AppVM as one of the test cases.
- Speaking of different Linux distros -- we have also recently built and released an experimental (“beta”) Debian template for Qubes AppVMs, a popular request expressed by our users for quite some time. It can be readily installed with just one command, as described in the wiki. It is supposed to behave as a first class Qubes AppVM with all the Qubes signature VM integration features, such as seamless GUI virtualization, secure clipboard, secure file copy, and other integration, all working out of the box. Special thanks to our community contributors for providing most of the patches required for porting of our agents and other scripts to Debian. This template is currently provided via our templates-community repo, but it nevertheless has been built and signed by ITL, and is also configured to fetch updates (for Qubes tools) from our server, but we look forward for somebody from the community to take over from us the maintenance (building, testing) of the updates for this template.
- Also in our "Templates Appstore" you can find now an experimental “minimal” fedora-based template, which might be used by more advanced users to build customized special-purpose VMs and templates.
- We have also moved our Wiki server to a bigger EC2 instance so it could better handle the increased traffic and also added a real CA-signed SSL certificate! But I encourage people to read why this is mostly irrelevant from the security standpoint and why they should still be checking signatures on the ISOs.
- We also got a new logo (actually we never really had our own logo before). This also means Qubes now got its own distinct set of themes for installer, plymouth and, of course, a bunch of cool wallpapers with Qubes logo nicely engraved on them. However, it turned out that convincing KDE to set our wallpaper as a default one exceeds the collective mental abilities of ITL, and so one needs to right-click on the desktop and choose one of the Qubes-branded wallpapers manually after install or upgrade.
- Every once in a while people (re-)discover that monolithic kernel-based desktop operating systems are not the best solution whenever the user even remotely cares about security...
- Yes, USB inherent insecurity, as well as widespread GUI insecurity, or networking stack insecurity, trivial physical insecurities, or sick permissions model as used in most desktop systems, have all been known facts for years. The recognition of these problems has been the primary motivator for us to start the work on Qubes OS back in 2009/2010.
- And yes, Qubes running on an appropriate hardware (specifically with Intel VT-d) can solve most of these problems. Correction: Qubes OS can allow the user or administrator to solve these problems, as unfortunately this still requires some configuration decisions made by the human operator. So today Qubes R2 is like a sports manual transmission, which requires a bit of skill to get most out of it. In the near future I see no reason why we should not be offering the "automatic 8-speed transmission" edition of Qubes OS. We just need more time to get there. The R3 release (Odyssey-based), whose early code is planned to be released just after the "final" R2, so sometime in September, is all about bringing us closer to that "automatic transmission" version.
- With my 10+ years of experience as a system-level security researcher, I believe there is no other way to go. Don't get deluded that safe languages or formally verified microkernels could solve these problems. Security by Isolation, done sensibly, is the only way to go (of course it doesn't preclude making use of some formally verified components, like e.g. microkernel in place of Xen, at least in some editions of Qubes).
New in version 2 RC1 (April 22nd, 2014)
- Both Dom0 and VMs have been upgraded to Fedora 20.
- Support for full templates download via two new repo definitions: templates-itl and templates-community. With a bit of imagination we could call it Qubes “AppStore” for VMs :) Currently we have only published one template there – the new default fc20-based template, but we plan to upload more templates in the coming weeks (such as the community-produced Arch Linux and Debian templates). Even though we have a separate repo for community contributed templates, we still plan on building those templates ourselves, from (contributed) sources.
- Support for running Windows AppVMs in “full desktop” mode with support for arbitrary window resizing (which automatically adjusts the resolution in the VMs).
- Support for on-the-fly switching between the “full desktop” and “seamless” modes for Windows AppVMs.
New in version 2 Beta 3 (December 11th, 2013)
- The seamless GUI virtualization for Windows 7-based AppVMs, and support for HVM-based templates (e.g. Windows-based templates) is one of the most spectacular feature of this release, I think. It has already been discussed in an earlier blog post, and now instructions have also been added to the wiki for how to install and use such Windows AppVMs.
- We've also introduced a much more advanced infrastructure for system backups, so it is now possible to make and restore backups to/from untrusted VMs, which allows e.g. to backup easily the whole system to a NAS, or just to an USB device, not worrying that somebody might exploit the NAS client over the network, or that plugging of the USB disk with malformed partition table or filesystem might compromise the system. The whole point here is that the VM that handles the backup storage (and which might be directing it to a NAS, or somewhere) might be compromised, and it still cannot do anything that could compromise (or even DoS) the system, neither can it sniff the data in the backup. I will write more about the challenges we had to solve and how we did it in a separate blog post. I'm very proud to note that majority of the implementation for this has been contributed by the community, specifically Oliver Medoc. Thanks!
- A very simple feature, trivial almost, yet very important from the security point of view – it is now possible to set 'autostart' property on select VMs. Why is this so important for security? Because I can create e.g. UsbVM, assign all my USB controllers to it, and then once I set it as autostarting, I can have assurance that all my USB controllers will be delegated to such AppVM immediately upon each system boot. Having such a UsbVM is a very good idea, if one is afraid of physical attacks coming though USB devices. And it now could double as a BackupVM with this new backup system mentioned above!
- To improve hardware compatibility we now ship the installer with multiple kernel versions (3.7, 3.9, and 3.11) allowing to run the installation using any of those, e.g. if it turned out that one kernel doesn't support the graphics card correctly -- a typical problem many users faced in the past. All the kernels are also installed in the final system, allowing the user to easily boot with a select Dom0 kernel later, choosing the one which supports their hardware best.
- Another popular problem of the past now was the lack of support for dynamically changing resolution/screen layout in the AppVMs when a seccond monitor or a projector was hot-plugged in (which changed only the resolution layout in Dom0). Now this problem has been solved and the new monitor layout is dynamically propagated to the AppVMs, allowing to use all the screen real estate by the apps running there.
- There has also been a significant amount of cleanups and fixes. This includes the unification of paths and command names (“The Underscore Revolution” as we call it), as well as refactoring of all the source code components (which now closely matches what we have on Qubes Odyssey/R3), and lots of various bugfixes.
New in version 2 Beta 2 (March 1st, 2013)
- Upgraded Dom0 distribution to the latest Fedora 18 (all previous releases used Fedora 13 for Dom0!)
- Upgraded default VM template also to Fedora 18
- Upgraded Dom0 kernel to 3.7.6
- Upgraded KDE environment in Dom0 (KDE 4.9)
- Introduced Xfce 4.10 environment for Dom0 as an alternative to KDE
- A few other fixes and improvements, including the recently discussed Disposable VM-based PDF converter
New in version 2 Beta 1 (December 14th, 2012)
- Support for generic fully virtualized VMs (without qemu in the TCB!)
- Support for Windows-based AppVMs integration (clipboard, file exchange, qrexec, pv drivers)
- Secure audio input to select AppVMs (Hello Skype users!)
- Clipboard is now also controlled by central policies, unified with other qrexec policies.
- Out of the box TorVM support [http://wiki.qubes-os.org/trac/wiki/HvmCreate]
- Experimental support for PVUSB
- Updated Xorg packages in Dom0 to support new GPUs
- DisposoableVM customization support
- ... and, as usual, various fixes and other improvements
New in version Beta 1 (April 19th, 2011)
- Installer (finally!),
- Improved template sharing mechanism: service VMs can now be based on a common template, and you can now easily create many net- and proxy- VMs; template upgrades now don't require shutting down all the VMs;
- Standalone VMs, convenient for development, as well as for installing the least trusted software,
- Built in, easy to use firewall VM(s),
- Seamless integration of virtualized tray icons (check the screen shots!)
- Redesigned file-copy between domains (easier, more secure),
- Default template based on Fedora 14 (x64)
- Reasonably complete User Guide.