Qubes/Why use Qubes over other Virtualizers

< Qubes

Why Use Qubes Over Other Virtualizers?[edit]

The Qubes project is focused on developing the Qubes OS desktop operating system, which is based upon the principle of "Security by Isolation". It is not a general purpose operating system where the ability to install a virtualizer is just another feature. Rather, it runs a bare-metal virtualizer (Xen) and isolates hardware controllers and multiple user domains (qubes) in separate VMs that are explicitly assigned different levels of trust.


  • The Xen hypervisor and administrative domain (dom0) in Qubes OS actively discourages any activity other than running VMs.
  • The network stack and WiFi drivers are running in a dedicated, unprivileged network VM (NetVM), which substantially reduces the attack surface.
  • Enabling VT-d/IOMMU via BIOS provides DMA protection.
  • An additional firewall VM is used to house the Linux kernel-based firewall, providing extra protection against a compromised NetVM.
  • The USB stack can be isolated in a dedicated USB VM, protecting dom0 from untrusted USB devices.
  • Future separation of the GUI (graphical) domain from dom0 is planned.
  • By default, Qubes OS is firewalled and no incoming ports are open.
  • No networking is present in the administrative domain (dom0). Even dom0 upgrades are done in a dedicated UpdateVM (currently set by default to firewallvm), before those are verified and installed in dom0.
  • All TemplateVM and dom0 updates can be easily fetched over Tor via the Whonix-Gateway ProxyVM (commonly called sys-whonix).
  • DisposableVMs are available to open untrusted applications, links, attachments and documents. [1]
  • Anti Evil Maid (AEM) protection is supported.
  • Yubikey multi-factor user authentication is available to enhance the security of logins, mitigate the risk of password snooping, and improve USB keyboard security.
  • No microphones are attached to VMs by default.
  • TCP timestamps are disabled by default. [2]
  • ICMP timestamps are disabled by default. [3]
  • Unforgeable, colored window borders allow easy identification of qubes with different security levels.
  • PDFs can be easily sanitized via a trusted PDF converter.
  • Greater security of email-centric work environments is possible by using split GPG to protect private keys and limiting network connections exclusively to the chosen email server.
  • Protection against unintentional leaks of critical user data is possible by setting an empty NetVM field for the corresponding qube.
  • Tor Traffic can be white-listed using corridor as a filtering gateway, protecting against accidental clearnet leaks.
  • Availability of an experimental unikernel firewall based on MirageOS for greater security, performance and a lower resource footprint.
  • Joanna Rutkowska, security researcher, founder and developer emeritus of Qubes OS has completed a research paper comparing the security of software compartmentalization vs. physically separated computers (pdf). It concluded that in some cases, notably for specific, desktop-related workflows, Physical Isolation might be less secure than Qubes' compartmentalized approach.


  • OS agnostic: qubes can be based upon Fedora, Debian, Whonix, Windows, Kali Linux and Arch Linux templates, among others.
  • All isolated qubes are integrated into a single, usable system via a unified desktop.
  • Software installation and updates are centralized.
  • Creating new VMs and disposing of unwanted VMs is very easy and fast.
  • The VM start menu is integrated into the host's (dom0) start menu via Qubes VM Manager.
  • A secure and usable mechanism exists for copying and pasting clipboard contents and files between qubes.
  • An easier backup / restore mechanism for VMs.
  • The keyboard layout only needs to be configured once in dom0.
  • No duplicate task bars are present.
  • A default seamless mode is available for Windows (similar to VirtualBox’s Seamless Mode or VMware’s Unity Mode). [4] It is easy to distinguish which window belongs to each VM. [5]


  • VMs boot up much faster, because fewer services need to be started.
  • AppVMs therefore also use much less RAM.
  • AppVMs use far less disk space because they can share the root image of the TemplateVM in read-only mode. Separate disk storage is only used for the user's directory and per-VM settings (read more: TemplateImplementation).
  • Standalone VMs can be created for the installation of software in only specific domains.

Qubes-Whonix Advantages Over Non-Qubes-Whonix[edit]


  • It is easier to tunnel the whole system - including host (dom0) updates - through Tor (besides sys-net and sys-firewall).


  • Multiple Whonix-Workstations AppVMs can easily use the same Whonix-Gateway ProxyVM without being able to make contact with one another. [6]
  • Downloads of Whonix TemplateVM images use cryptographic signatures of the dom0 package manager (qubes-dom0-update / dnf). Without the user knowing it, this makes verification transparent.


Qubes Vulnerabilities[edit]

Qubes is not however a silver bullet - attacks are still possible against: the virtualization technology (VT-x, VT-d), the hypervisor (Xen), and additional software used by a virtualized system (e.g. qemu, DirectX emulation). Further, data leaks are possible via cooperative covert channels (malware working in concert across two or more VMs), and side channel attacks (malware in one VM trying to learn about processes executed in another VM).


https | (forcing) onion

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.

Whonix is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Libre Software license as Whonix itself. (Why?)