Field Notes

entity

Qubes OS

StatusStableReviewdue UpdatedStands on6 sourcesSupportsnotes

Qubes OS is a security-oriented desktop operating system that uses the Xen hypervisor to isolate applications into separate lightweight virtual machines called qubes. It was created by Joanna Rutkowska in 2010 and is currently at version R4.2, with R4.3 in development.

Security model

Qubes implements security-by-compartmentalization. Each application or activity domain (personal, work, banking, untrusted) runs in its own qube, which is a lightweight Xen VM. A compromise of one qube does not propagate to others unless the attacker escapes the hypervisor.

The architecture pushes security-critical subsystems out of the privileged domain (dom0):

  • Networking code runs in an unprivileged NetVM, isolated via IOMMU/VT-d.
  • USB stacks run in an unprivileged USB VM.
  • dom0 has no network code at all.
  • The GUI virtualization layer adds roughly 2,500 lines of C to dom0.

The TCB is on the order of hundreds of thousands of lines of C, several orders of magnitude smaller than mainstream operating systems.1

A 2026 analysis of the public advisory record from 2011 to 2025 found that 87 of 109 Qubes Security Bulletins (QSBs), or 79.8%, are attributable to upstream dependencies (Xen, CPU microarchitecture, Fedora integration) rather than Qubes-core logic.2 That figure describes what the project disclosed, not what existed: the advisory record is generated by Qubes’s own process, so it cannot by itself establish whether Qubes-core is sounder than its dependencies or merely less studied than Xen and CPU microarchitecture. Qubes OS Security in the Public Record sets out both the numbers and that limit.

Templates and updates

App qubes share templates (typically Fedora-based, with Debian and Kicksecure also available), allowing centralized updates across all qubes derived from the same template. Disposable qubes self-destruct after use, providing amnesic sessions for untrusted content.

Inter-qube communication

Copy-paste and file transfer between qubes require explicit user action via the qrexec framework. The color-coded window border system visually indicates each qube’s trust level.

Hardware requirements

Minimum: 64-bit CPU with Intel VT-x/EPT or AMD-V/RVI, VT-d/IOMMU, 6 GB RAM, 32 GB storage. Recommended: Intel processor (AMD not recommended due to inconsistent security support on client platforms), 16 GB RAM, 128 GB SSD, Intel IGP. A TPM is required for the optional Anti Evil Maid feature. Hardware compatibility is not guaranteed even when minimum requirements are met; the project maintains a hardware compatibility list.

Relationship to Whonix and Kicksecure

Qubes supports Whonix templates (Qubes-Whonix) for anonymous communication via Tor. Kicksecure templates are also available, providing a hardened Debian base for app qubes.

Limitations

The VM-per-application model imposes significant RAM overhead. Gaming is impractical. GPU support is limited (Intel IGP strongly recommended, Nvidia problematic). The learning curve is steep, typically requiring weeks to reach comfortable daily use. Hardware compatibility remains a friction point. Microarchitectural side-channel attacks (transient execution vulnerabilities) account for 23 of the 73 post-2018 bulletins, or 31.5%, and are not fully fixable in software.2 They are the clearest case of the architecture’s dependence on a trust anchor the project does not control: compartmentalization assumes the hardware keeps the compartments apart.

The isolation guarantee has also failed outright. XSA-212 in 2017 allowed a paravirtualized guest to read and write hypervisor memory, and the published exploit ran commands as root in every other PV guest including dom0; Qubes stated that such a bug lets an attacker who has already compromised a browser “compromise a whole Qubes system.” XSA-148 in 2015 affected Qubes similarly. Qubes answered by dropping PV in 4.0 for hardware-enforced memory virtualization, which retired that bug class and moved the guarantee’s foundation into the processor. Xen isolation failures affecting Qubes OS holds both documents.

See also

  1. Qubes OS architecture documentation (Qubes OS project, developer documentation on system architecture and security-critical code); saved architecture page and saved security-critical code page. First-party documentation, so it states the design as intended rather than as audited. ↩

  2. Qubes OS Security in the Public Record (Alfonso De Gregorio, preprint posted to arXiv 16 July 2026, arXiv:2607.14587); saved PDF. Codes 109 Qubes Security Bulletins issued between 2011 and 2025 against the Xen advisory tracker. A preprint, not yet peer reviewed. ↩↩

Built on 6 sources (6 external).

Working out connections…