Security

From a strict security perspective, Qubes OS is not reliable

Written by FlyWithMe (a SimpleX chat user) — Updated July 5, 2026

This article is a critical look at Qubes OS, or "XenOS" as I sometimes call it. I focus on its security weaknesses, note where its design is useful, and suggest improvements and more reliable alternatives for different kinds of users.

1 - Xen hypervisor

Qubes OS runs virtual machines on Xen, a type-1 hypervisor. Because Xen runs directly on hardware (Ring 0), virtualization does not automatically provide stronger security than bare metal (also Ring 0). The hypervisor isolates and manages VMs, but it also becomes a central point of trust. If the hypervisor is compromised, the impact can exceed that of an equivalent failure in a single operating system kernel. Hardware and firmware flaws (for example, microcode and speculative-execution issues) can also weaken isolation.

In reality, with Intel and AMD's virtualization extensions (VT-x and AMD-V), the hypervisor does not run in the guest's Ring 0: it runs in VMX root mode / host mode (the so-called logical "ring −1"), while the virtual machine kernel continues to see itself as Ring 0, but in practice runs in VMX non-root mode / guest mode. This gives the hypervisor additional control and privileges over the hardware and VMs; therefore, if the hypervisor is compromised, the impact and scope of the attack can be much greater.

Xen also uses paravirtualization, a virtualization technique that involves modifying the guest operating system, providing a software interface to virtual machines that is very similar to, but not identical to, the underlying hardware. In this model, guest systems are aware they are virtualized and communicate with Xen through hypercalls. That design improves performance, but it also introduces additional interfaces and direct dependencies between guest and hypervisor. Those interfaces increase complexity, attack surface, and opportunities for misconfiguration. This is the price to pay when choosing usability over security.

Xen supports hardware-assisted virtualization (HVM) with Intel VT-x and AMD-V. Full virtualization can run unmodified guest operating systems and usually provides stronger isolation characteristics than paravirtualization. Qubes OS relies too much on paravirtualized paths in most templates, and this is a security weakness. Xen offers five approaches to running the guest operating system, but only the Microsoft Windows template in Qubes OS supports fully hardware-assisted virtualization.

This is a problem, because the less secure the guest operating system is, the more vulnerable it will be to being exploited in a direct attack on the hypervisor. Which means that while using the Windows template in Qubes OS is necessary to have a more secure form of virtualization, it is also the most insecure possible way to protect yourself against attacks. After all, Windows isn't known for being secure...

In comparison to paravirtualization, full virtualization completely emulates the underlying hardware in a virtual machine, which means the VM is fully isolated from the host system without requiring guest-side modifications. This usually costs more resources, but can simplify trust boundaries. Examples of full virtualization with hardware-assisted virtualization include KVM, Hyper-V, VirtualBox, and OpenBSD VMM.

Several attacks on Qubes OS originate in an AppVM, and some historical exploits have used Xen vulnerabilities to escape the guest and compromise Dom0 or other VMs. However, not all attacks go through Xen—there are also vectors via firmware (ME/PSP), drivers, IOMMU, or flaws in Dom0 and SystemVMs. The most important link in the system is also the most vulnerable, so vulnerable that support for using OpenBSD for dom0 and domU has been officially proposed and debated, with broad agreement that it would be very good and extremely beneficial for the security of Qubes OS. However, this does not happen because OpenBSD is incompatible with Linux and other software.

https://github.com/QubesOS/qubes-issues/issues/4551

The use of OpenBSD for NetVM (sys-net) was also proposed, due to its extreme vulnerability to attacks. Almost all arguments were in favor, but admitted the impossibility due to incompatibility:

https://github.com/QubesOS/qubes-issues/issues/5294

Update: Apparently it's possible to use OpenBSD as sys-net, although I'm not sure it would be fully compatible as a NetVM. The guide is outdated and it isn't officially supported by the Qubes OS team:

https://forum.qubesos.org/t/fortifying-sys-net-a-shift-to-openbsd/31973

But all this would only remedy the inevitable: the hypervisor will always be the weakest link. An OpenBSD running directly on the hardware tends to have a smaller attack surface than when running on a VM, because virtualization adds layers (hypervisor, firmware, drivers, devices) that broaden the risk surface. Many believe that the fact that dom0 does not connect to the internet makes it 100% secure, which is not true.

An exploited NetVM can, for example, serve as a starting point for attacks that escape to other VMs or to dom0, compromising the entire system. The fact that dom0 does not have internet access is good for protecting against remote attacks targeting dom0, which attempt to "bypass" the need to escape from a VM to access it; this simply does not protect against the escape of one or more compromised VMs. Logical isolation loses effectiveness if all VMs and services depend on the same underlying platform (in this case, Xen). Even Hyper-V (the Windows hypervisor) has had far fewer CVEs and VM leaks than Xen in recent years. The Windows virtualizer security model is more mature, especially on supported enterprise hardware, than Qubes OS.

I could write another 10,000 lines about why hypervisors and virtual machines are unreliable and insecure, covering everything from hardware architecture to software. However, I will quote only one response here from Theo de Raadt (creator of OpenBSD) to OpenBSD users discussing the Xen hypervisor and whether OpenBSD intended to implement Xen or something similar:

Theo de Raadt on Virtualization Security

Virtualization seems to have a lot of security benefits.
Adam Getchell, OpenBSD Misc Mailing List

You've been smoking something really mind altering, and I think you should share it.
x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.

You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

You've seen something on the shelf, and it has all sorts of pretty colours, and you've bought it. That's all x86 virtualization is.
Theo de Raadt, OpenBSD Misc Mailing List

In the scientific cluster computing and enterprise spaces, it's already well demonstrated, by many, many practitioners in those fields, that virtualization is a very, very good tool.
Adam Getchell, OpenBSD Misc Mailing List

So what? Someone showed up here and said it is actually all about security.

That is obviously false to anyone skilled in the field. You don't build better security by building another gigantic layer. That is obvious to anyone who actually works in the field.

The people who are being fooled are just being 'users'. They need it, so they invent all sorts of judgements to make it OK.
Theo de Raadt, OpenBSD Misc Mailing List

In the meantime, virtualization provides a great solution for those applications that benefit from running separately & isolated...
L. V. Lammert, OpenBSD Misc Mailing List

You believe it does seperation and isolation?
Theo de Raadt, OpenBSD Misc Mailing List

...while maximizing h/w utilization.
L. V. Lammert, OpenBSD Misc Mailing List

This, it does do. But the people who want to maximize hw utilization are trying to lie to themselves about the security aspects.

You can't run more code and then have less failures.
Theo de Raadt, OpenBSD Misc Mailing List

No matter how you twist the logic, however, a VM provides a good level of application domain security, from the standpoint that each set of domain users and applications can only see the services provided within that domain guest OS.
L. V. Lammert, OpenBSD Misc Mailing List

It's that extra 4MB of poo code, that is what makes it more secure.

It's slippery and sticky at the same time, so that the application attackers slip and slide and fall into the page boundaries.

If the actual hardware let us do more isolation than we do today, we would actually do it in our operating system.

The problem is the hardware DOES NOT actually give us more isolation abilities, therefore the VM does not actually do anything what the say they do.

While x86 hardware has the same page-protection hardware that an IBM 390 architecture machine has, modern PC machines are a mess.
Theo de Raadt, OpenBSD Misc Mailing List

These are not appeals to authority, they are shared technical assessments. Theo de Raadt's critique represents a long-standing position from one of the most respected security-focused OS developers: virtualization adds complexity and does not automatically improve security—it often does the opposite.

The argument I see most often from Qubes OS developers is dismissive: "A hypervisor escape is rare," "these attacks are difficult to carry out," or "you have no reason to worry about it." That misses the point entirely. Xen has accumulated hundreds of published XSAs (Xen Security Advisories) since its inception, many of them critical, including numerous guest-to-host escape vulnerabilities. By comparison, KVM and Hyper-V have had far fewer escape-class vulnerabilities in the same period. Hypervisors still benefit from a kind of security by obscurity, because most commodity malware does not expect to be running inside a VM and therefore does not bother attacking the hypervisor.

If this model becomes more popular (and it is), attackers will have more reason to target hypervisors, especially Xen. Qubes OS also does little to hide the fact that a guest is virtualized, which makes this problem easier to recognize from inside a VM. That brings us to the next issue.

2 - Lack of VM spoofing

In most VM setups, guest systems can easily detect that they are virtualized. On Windows, this can be visible through registry keys, drivers, processes, and other system artifacts.

An example of this fact is that when using both Windows and Tails (Linux) in a virtual machine, you will receive a notification from the guest OS indicating that the system is being virtualized.

This is why Tails warns you when it is running inside a virtual machine
https://tails.net/doc/advanced_topics/virtualization/index.en.html

This can be masked. There are many scripts and tutorials that try to hide virtual machine presence from the guest, and on Linux this can be easier because the user has more control over the environment:

Qubes OS does not try to do this kind of concealment, so malware can detect the VM context early and adapt its behavior, or an attacker with remote access may, upon realizing that they are in a virtualized environment, seek to exploit the hypervisor.

Because Qubes templates are already modified operating-system images, implementing spoofing should not be an absurd idea. Qubes OS could improve here if the developers wanted it.

3 - Linux-based attack surface

Qubes OS uses a Fedora-based dom0 and standard Linux kernels. My argument is that this inherits Linux and Fedora risks, and does not automatically give users a stronger baseline than a well-hardened non-Qubes system.

Qubes OS dom0 is maintained on a Fedora base that I consider outdated, relatively weak, and unstable for this role. The standard Linux kernel lacks many security mitigations and memory-safety protections found in hardened alternatives. Compared with hardened Linux variants or security-focused operating systems, the default Linux baseline is very insecure.

A compromised 'sys-net' can expose memory from other qubes. When concerns like this are dismissed as rare buffer-overflow or memory attacks, the dismissal is wrong. In software written in C, roughly 66-70% of vulnerabilities are related to poor memory management.

See my other article proving this: The C language and its biggest problem: evidence of its insecurity.

Attackers target the weakest link. Compartmentalization helps only when the privileged components underneath it are robust and patched quickly.

Qubes OS could improve this with kernel security patches such as Grsecurity/PaX and/or Linux-hardened support, LKRG, and compilation with hardening flags such as FORTIFY, PIE, and RELRO. It should also lean harder on Mandatory Access Control, such as TOMOYO or SELinux. Fedora templates support SELinux on Qubes OS, but the setup is outdated, the default policies are weak, and enforcing mode is not practical without breaking the system.

Fedora Secureblue is a good example of the bare minimum for a "reasonably secure operating system": kernel patches, hardened system defaults, and a strong MAC model with limited namespaces. Qubes OS does not do this by default.

4 - Operational complexity

Qubes OS is operationally complex, even for advanced users. More complexity means more chances for human error, and human error can weaken both security and anonymity.

Qubes OS is not secure by default, and its current architecture cannot get there.

In short, more moving parts usually mean more opportunities for mistakes and misconfiguration. Complexity = Attack Surface, always.

5 - Systemd attack surface

I criticize systemd here for its size and complexity. One practical check worth running is systemd-analyze security to review service hardening baselines. The templates for dom0 and NetVM also do not perform any hardening on systemd, unlike other systems focused on security such as Secureblue.

Systemd centralizes many responsibilities. That concentration increases attack surface and raises the impact of failures. Systemd is currently divided into 5 layers:

4. systemd Utilities
2. and 3. systemd daemons and systemd targets
1. systemd Core
0. systemd Libraries (the base)

Each layer has several programs and modules, which add even more attack surface. It's almost like a complete operating system; in fact, a kernel plus systemd is already a complete operating system.

6 - Hardware support and compatibility problems

Qubes OS hardware compatibility is narrow in practice, especially when stable IOMMU, SLAT, and all Qubes OS features are required without workarounds. Having 100% compatibility with the Linux kernel in its latest version + Qubes OS in its latest version + IOMMU + SLAT + HVM (+ TPM 2.0 if you want it) is a real Russian roulette.

https://www.qubes-os.org/hcl

Getting full hardware compatibility with this OS feels like playing the lottery. Outside the small certified-hardware list, it is hard to know which devices are truly stable and which are effectively experimental. That list has only 11 devices, and three of them no longer receive CPU microcode updates.

If you look closely at the "Remark" field (HCL page), you'll see ridiculous bugs and/or workarounds to make the system work, such as:

"No resume after suspend"
"legacy boot (not UEFI)"
"Required workaround for sys-net, read more"
"Need BIOS legacy mode for install"
"Audio, bluetooth, HDMI not working. Display needs thunderbolt (displayport?)."
"sys-net needs to run in PV (paravirtualized mode, wake to black screen, R4.0.4 installer won't work, R4.1 won't work"
"Turn secure boot off, use non-uefi install option"
"Required altering boot args, read more"
"Needs published EFI workaround to boot, Nvidia workaround not to OOPSing during install."
"device instability (webcam, bluetooth adapter)"
"Enable legacy CSM and disable secure boot"
"Occasional momentary performance / freezing / connectivity issues, read more"
"issues with assigning PCI devices"
"Had to remove PCI devices from sys-net."
"Most features work on 3.7 and 3.11, but for best results use 3.9." (Had to downgrade the version, how absurd)
"VDM Mode must be disabled."
"Wifi works, ethernet doesn't" (First time I've seen something like this)
"Problems with suspend locking, HVMs crashing. Applied EFI fix, read more"
"Network VM workaround, read more"
"NetVM hangs computer"
"Suspend leaves network frozen" + "Used installer workarounds, read more"
"Works"flawless" after BIOS tweaks, read more"
"bus reset issue with wired network"
"no suspend/reboot; cold boot and normal shutdown work"
"TPM needs downgrading to TPM v1.2 read more" (again. At least version 1.2 of TPM has less attack surface.)
"Disabled TPM to get UEFI working"
"To boot the installer, you need to remove mapbs=1 and noexitboot=1 To get suspend to work, you need to add mem_sleep_default=deep to the kernel= line in /boot/efi/EFI/qubes/xen.cfg."
"Runs only with kernel 3.9 read more" (This is extreme)
"AEM works with TPM v1.2 mode, but not v2.0." (Seriously. AEM = Anti Evil Maid)
"Hyperthreading must be disabled (only on i5), actvated TPM slows down the system" + "Intel graphics unusable with enabled VT-d"
"Suspend doesn't work on 3.7.6 kernel, but work on 3.7.4"
"Bios Legacy Mode" + "Upgrade to rc4 broke networking"
"Needed graphics, UEFI workarounds, read more, read more Added TB served devices to sys-net."
"needs older WiFi driver" (Needing an outdated version again.)
"AEM workaround; compile Wi-Fi driver, read more"
"needs kernel downgrade to 3.7.4"
"No IOMMU – not recommended for Qubes OS!" (For obvious security reasons)
"Issues with UEFI boot and sys-usb; Cannot wake from sleep; read more"

I could go on, and this still would not cover even a third of the hardware/software problems users report. Many setups require downgrading the kernel, drivers, or OS version just to work "correctly".

This is a widespread problem. Qubes OS is far from having hardware compatibility that I would call stable and reliable. Fixing that would require a huge amount of engineering work, and the problem is specific to Qubes OS rather than inherent to Linux systems in general.

So if you do not have one of the following 11 devices, you should assume you may not get full support for all Qubes OS features, including some basic security features and vulnerability fixes (either from vendors, Linux or Qubes OS). Do I need to explain why this is a serious problem from a security perspective?

https://doc.qubes-os.org/en/latest/user/hardware/certified-hardware/certified-hardware.html#qubes-certified-computers

Pay attention to what the developers themselves say on the official website:

There is a class of security vulnerabilities that can be fixed only by microcode updates. If your computer or the CPU in it no longer receives microcode updates (e.g., because it is too old), it may not be possible for some of these vulnerabilities to be mitigated on your system, leaving you vulnerable.

This matters because Qubes OS depends heavily on CPU virtualization features such as Intel VT-x, Intel VT-d, AMD-V, and AMD-Vi. Its security depends on vendor microcode that supports those features, so vulnerabilities in that hardware or microcode affect Qubes directly. That dependency is ugly: the OS needs proprietary CPU code both to function/exist and to claim security.

In that sense, the security of Qubes OS depends less on Qubes itself and more on Intel and AMD engineering. This increases attack surface for both the OS and Xen instead of reducing it, and that dependency cannot be wished away.

One major and serious problem that no one seems to realize is that Qubes OS, being "an operating system for only 11 selected hardware devices," makes it extremely vulnerable to coordinated and focused attacks, such as hardware backdoors and supply-chain attacks. Look, if you know that a specific group of people (the ones you want to target) use specific devices from specific vendors, it becomes much easier to poison the food chain. And this isn't something I made up. The FBI (and intelligence agencies like NSA and Mossad) have done this many times, one instance being when they sold a cell phone through a front company promising it was "an extremely secure and private phone," which many criminals bought, used, and were subsequently arrested (more than 800 criminals were arrested).

https://www.justice.gov/usao-sdca/pr/fbi-s-encrypted-phone-platform-infiltrated-hundreds-criminal-syndicates-result-massive

So, besides Qubes OS having such significant hardware limitations, it makes supply-chain attacks even easier because it's an operating system that relies on Intel and AMD's microcode/virtualization technology. Compromising that would compromise all users of this operating system. I'm not saying Qubes OS is the only OS vulnerable to hardware backdoors; in fact, all OSs are, but Qubes OS is the MOST vulnerable to this type of thing. A Linux or BSD user who doesn't use virtual machines doesn't need to worry about backdoors in the specific CPU's virtualization technology microcode, nor on 11 specific devices.

And it gets even worse when dom0 can only use Fedora, meaning, "it got 1000 times worse!", compromising the Fedora repositories makes any update to dom0 a total system breaking point, Game Over. There is no salvation for Qubes OS.

7 - TPM 1.2/2.0 requirements

Qubes OS needs TPM 1.2 support to implement the basics of AEM (Anti Evil Maid). Without it, the system is presented as highly vulnerable to physical attacks. My criticism is simple: a system praised as secure can become very weak once physical compromise enters the threat model, and "requires" more proprietary and vulnerable code to "protect" itself?

https://doc.qubes-os.org/en/latest/user/security-in-qubes/anti-evil-maid.html

But that is not the problem, the real problem is that TPM2 adds more code, firmware, and initrd complexity (tpm2‑tss, stack integration, dracut/hooks, crypttab, signed UKIs and operational dependencies). That raises the boot‑time (which is more attack surface) and operational fragility. Misconfiguration can also break boot or weaken security. TPM2 relies on vendor (closed-source) firmware and tpm2-tss implementations, firmware or vendor backdoors/bugs in TPM microcode are a single point of persistent compromise. If TPM firmware (or Intel PTT/ME interactions) is compromised (even remotely), TPM attestation/sealing can be subverted and used to hide persistent tampering from the user.

Many TPM vulnerabilities have already emerged, which require more patches from vendors, and if you don't have supported hardware, you will be out of date in security fixes (this happens sooner or later).

The TPM acts more like a backdoor than anything else. TPM manufacturers/suppliers have a unique identification key (EK) that, if linked to an actual identity or shared with third parties, could allow device identification or correlation. These keys can be easily discovered through the operating system (especially Windows), and malware could use this to totally deanonymize a Qubes OS user in the future through the TPM unique ID, which consists of hardware identifiers. That is, if you did not buy your device in a 100% anonymous way, it's over. Not to mention all the other remote vulnerabilities involving TPM.

This could easily be mitigated if Qubes OS did not support TPM or most TPM-based features (like OpenBSD, whose TPM "Functionality is limited to instructing the device to save its state before a system suspend."), so it would be impossible to access such keys without physical access. And TPM 2.0 is even worse than 1.2: much more code and complexity (in other words, much more attack surface).

More on this topic from an authority in the field: https://inv.nadeko.net/watch?v=t1eX_vvAlUc

Qubes security guidelines dictate that USB devices should never be attached directly to dom0, since this can result in the entire system being compromised. However, in its default configuration, installing and using AEM requires attaching a USB drive directly to dom0.

This is a strong contradiction in the default security model. You are saying that to be "safe" I need to do something that could compromise my system completely?

(The other option is to install AEM to an internal disk. However, this carries significant security implications, as explained here.)

In other words, to get "security" you need to do something risky enough to compromise the system. Wonderful.

This presents us with a classic security trade-off: each Qubes user must make a choice between protecting dom0 from a potentially malicious USB drive, on the one hand, and protecting the system from Evil Maid attacks, on the other hand.

That trade-off is too costly and is disrespectful to users who want physical-attack resistance without adding another high-risk step.

8 - Intel ME dependency

Devs: If you cleaned your Intel Management Engine with e.g. me_cleaner while installing coreboot (or libreboot) then you are out of luck. For now you have to choose between cleaning your BIOS and deploying Anti Evil Maid.

Relying on Intel ME for parts of the Anti Evil Maid workflow is a serious dependency, and Qubes does not treat it seriously enough.

Intel Management Engine (ME) runs at a more privileged level than the OS kernel or even then a type-1 hypervisor, it can be considered "Ring -3" (Below the CPU or kernel ring 0). Intel ME runs its own proprietary microkernel and firmware on its hardware independent of the BIOS/UEFI and operating system, runs independently of the main CPU. It is turned on and running even after turning off the device and is able to connect to the internet independently. Other magic powers include:

Intel ME is powered by a minimum power source while the motherboard is connected to the power (S0ix/Standby/even with OS shut down). So any power source like a notebook battery or residual energy feeds the IME 24 hours a day.
IME has its own MAC and IP address for out-of-band management interface, has access to the network controller (NIC) or can use an integrated network controller managed by ME, allowing for network communication independently.
Implements a network channel and TCP/IP stack itself or proxy through NIC to receive remote management commands (e.g. wake, KVM, provisioning).
In modes such as "Out-of-Band" (OOB) the ME/AMT responds to special packages sent by the management infrastructure, enabling diagnosis and remote access. This means that if your device has any problems, they can remotely access it for analysis and control. This can be done by official website online support… Crazy.

Many serious vulnerabilities have already emerged in the IME, including remote vulnerabilities, this not only affects Qubes OS, but it insists on creating a greater dependency between the IME and the system. https://www.cve.org/CVERecord?id=CVE-2024-49079
AMD has something similar called PSP, but it doesn't seem to be able to connect to the internet? Libreboot/Coreboot removes this as well. Furthermore, Libreboot is far superior to UEFI SecureBoot. https://libreboot.org/docs/linux/grub_hardening.html

Vulnerabilities or backdoors in these subsystems (Intel ME or AMD PSP) can allow access to VM data or compromise isolation. In fact, can compromise the entire device.

More on this topic from an authority in the field: https://inv.nadeko.net/watch?v=B4cOQOXjxew

The truth is that a physical attack on the device is usually game over. TPM, and especially Intel ME, cannot save you from hardware compromise. The better goal is to protect the operating system and the data stored on disk through software: full disk encryption, including the boot partition where possible; filesystem verification such as NetBSD Veriexec; immutability; and kernel hardening. If the machine is physically compromised, you should at least be able to move the HDD or SSD to another computer safely.

There is no guarantee that TPM, Intel ME, or proprietary firmware code was not compromised before you bought the computer. There is also no meaningful way for ordinary users to verify their reliability. What is guaranteed is that these components add attack surface and more places for malware to hide.

Does Qubes use full disk encryption (FDE)?

By default, Qubes OS uses LUKS/dm-crypt to encrypt everything except the /boot partition.

That is why I describe Qubes OS as vulnerable to physical attacks while depending on two backdoor-like components to "be secure." Meanwhile, several Linux systems support encryption of the /boot partition, or could support it with the right file system. Other operating systems have (or can have) similar protections too, including GrapheneOS, OpenBSD, NetBSD or any Linux distro with GRUB as a bootloader.

9 - Weak fit for server workloads

Qubes OS is a poor fit for server use. A system that claims serious security should also hold up in reliability-focused server contexts.

Server-oriented operating systems are often treated as more secure than their desktop-focused relatives for a reason. Windows Server is much stronger than regular Windows, Red Hat Linux is stronger than Fedora, and Ubuntu Server follows the same pattern. FreeBSD is very strong, and OpenBSD is the most secure BSD and one of the most secure operating systems ever made. They all have something in common: they were built with server needs in mind. If an operating system is bad or useless for servers, that is a serious warning sign. RHEL, FreeBSD, and OpenBSD can still be used on desktops.

Server quality is not optional for a system that aims at security. It requires availability, integrity, scalability, stability, and reliability. Those qualities naturally support security. A system like Qubes OS, which is not even reliably stable across hardware, should be much more modest about its security claims.

Qubes were designed to be disposable, not permanent. That runs against what a server needs, and it makes Qubes OS a poor choice for safe, available, reliable, long-term storage. Its main security mechanism—throwing away compromised or suspicious qubes—also reads like an admission that the system expects compromise. It feels like saying, "Qubes OS is safe because if malware appears, you can try to shut down the VM before it spreads." That is like running through rain and calling it a dry-weather strategy.

For Qubes OS to become credible as a server-focused platform, it would need a major redesign, probably from scratch.

10 - Networking exposure: trust in NetVMs and the split‑driver model

Qubes centralizes network access in one or more network‑facing qubes (NetVMs) and uses a split‑driver model that places privileged driver frontends in unprivileged domains, concentrating attack risk on those domains.

NetVMs are the primary external attack surface. Any remotely exploitable flaw in a network-facing qube (browser rendering engine, SSH, Tor client, VPN daemon, kernel network stack) or in the paravirtualized network device frontends can be used to pivot toward the hypervisor or other qubes. Split drivers reduce driver code in dom0, but expose complex device‑frontends and device‑backend channels (hypercalls, shared memory, event channels) that have been the vector in many hypervisor‑escape designs. Network‑facing qubes routinely need wide protocol stacks and third‑party code (wireless firmware, userland VPNs, DNS, TLS libraries), all large, frequently changed attack surfaces.

Remote exploitation of NetVMs can lead to persistent compromise of network qubes and staged attempts at privileged escapes, data exfiltration, or manipulation of other qubes' network traffic. For attackers, NetVM is the obvious target: it is exposed, important, and fragile.

Qubes OS could improve this by supporting alternative NetVMs such as OpenBSD, hardened Linux, pfSense, and OPNsense. Users can also move parts of the network stack to an external appliance, such as a physical router or firewall, to reduce local exposure. But at that point, though, I would rather use a different OS entirely.

11 - Forensics, logging, and incident response limitations

Qubes' compartmentalization and disposable‑qube model complicate centralized, tamper‑evident logging and post‑incident forensic analysis, reducing assurance after a suspected compromise.

Effective incident response relies on reliable logs, chain‑of‑custody for evidence, and the ability to reconstruct an attacker's actions. Qubes encourages ephemeral qubes and per‑VM storage; by default logs are scattered across multiple filesystems in different security domains and may be discarded with disposable qubes. Isolated qubes with differing trust levels can intentionally block or tamper with logging for plausible deniability (something that Qubes OS is bad at proving compared to other alternatives like Tails).

This can leave users unable to tell whether their system has been compromised. Instead of reducing damage, the model can make the attacker harder to see and therefore more comfortable staying inside the environment.

After a breach, investigators may find incomplete telemetry, missing cross‑qube event correlation, and lack of secure, centralized audit trails. That reduces the ability to determine scope, persistence, and exfiltration, and it complicates proving whether a host‑level compromise occurred (hypervisor/dom0) versus a guest compromise. For high‑assurance environments this weakens incident handling and forensic confidence. In the worst case, malware can remain active without the user's knowledge because the evidence needed to prove compromise was never preserved. That is not a small weakness.

Mitigations have limits. Best practice is to forward immutable, signed logs off‑host to a remote collector under operator control (write‑once storage or secure SIEM); use cryptographic attestation where possible; and maintain dedicated, high‑trust audit qubes with strict ingestion policies. These measures add operational complexity and still require careful threat modeling to avoid introducing new attack channels. At that point, I would rather look for something simpler and stronger.

12 - High-threat-model and enterprise support limitations

Qubes OS is poorly suited for enterprise and regulated environments because it lacks the operational infrastructure that enterprise/industry security depends on. For companies with serious compliance and response requirements, it is a bad fit. This is not a bug so much as a design choice, but the consequences are real.

If Qubes discovers a critical hypervisor vulnerability on a Friday afternoon, there is no SLA requiring a patch within 24 hours.

Qubes lacks broad commercial vendor support, certified long‑term platforms, and enterprise SLAs (Service Level Agreement) that organizations rely on for managed incident response and guaranteed security updates.

Enterprises and high‑assurance deployments expect vendor accountability: predictable patch timelines, coordinated disclosure, tested updates for large fleets, and contractual incident response. Commercial server OS vendors (RHEL, Ubuntu LTS, AlmaLinux/Rocky Linux, Windows Server) or OSes with commercial support ecosystems (FreeBSD, OpenBSD, NetBSD) provide certified hardware stacks, long support windows, livepatching, and support contracts - all essential for production security operations. Qubes' community‑driven model offers technical guidance and timely advisories for affected components, but it does not replace formal vendor SLAs or large‑scale patch‑validation workflows.

Organizations adopting Qubes face higher operational risk: ad‑hoc update procedures, limited certified hardware choices, no commercial guarantee of coordinated response at scale, and potential incompatibilities with enterprise management/orchestration tooling. This increases the cost, complexity and uncertainty of deploying Qubes in corporate, critical‑infrastructure, or regulated environments. In addition, Qubes remains limited to ~10 laptop models without vendor validation.

RHEL (Red Hat Enterprise Linux) for example can push patches to +10,000 workstations via satellite:

Qubes requires manual updates or ad-hoc scripting. For a regulated environment (healthcare, finance), this violates compliance expectations for "vendor-managed" security.

Qubes rejects enterprise reality for experimental isolation. BSD operating systems, or other Linux operating systems, offer compartmentalization, stability, and security (containers, user-space sandboxing, predictable and fast security/bug patches, kernel-level randomization, and mitigations) with vendor accountability, something Qubes cannot match. For enterprises, regulated sectors, or high-risk operations requiring SLAs; BSDs or enterprise Linux OSes are the proven and scalable choice.

13 - Security through virtualization, but is that all?

The core problem is architectural imbalance. Qubes presents compartmentalization as the main and only defense, while other layers remain weaker or inconsistent. A security model cannot depend on one strong component while leaving too much complexity and attack surface everywhere else.

Qubes OS places too much trust in virtualization and in a hypervisor maintained by a separate upstream project. That should be weighed against system-wide stability, update coordination, and maintainability.

The practical question is why anyone should prefer this stack over alternatives that use different (and even more secure) hypervisors and simpler host configurations while still supporting similar guest workflows.

You can use Whonix, BSDs, Windows, macOS, and many other systems on Linux through KVM, which Whonix officially supports. Why would running Whonix on a weaker hypervisor make you safer or even more anonymous? For this use case, I would rather use Fedora Secureblue, Alpine, Void, Gentoo Hardened, or another system I trust more than Qubes OS. Full virtualization can run operating systems without Qubes-specific template modifications. I do not see the logic in claiming that modified templates on Xen are safer than the same operating systems running natively or under a better-supported virtualization stack.

The main way Qubes OS provides privacy is via its integration with Whonix. Qubes OS does not claim to provide special privacy (as opposed to security) properties in non-Whonix qubes. This includes disposables.

https://doc.qubes-os.org/en/latest/introduction/faq.html#what-about-privacy-in-non-whonix-qubes

Yet another statement proving that everything Qubes OS "possesses" doesn't belong to them; nothing inherent in this operating system is their own (Xen, Whonix, Intel/AMD technology, Linux), and they aren't even ashamed to admit it. That's because Whonix is the only VM system that protects against VM fingerprinting and advanced deanonymization attacks.

This also increases the complexity of maintaining and organizing the system, since Xen, Whonix, Fedora, and other Qubes dependencies are maintained by different developers with different goals. If a bug or security vulnerability is discovered in Xen, for example, Qubes developers are limited by what the Xen project fixes upstream.

So again: why use Qubes OS for this when you can run more operating systems in virtual machines on platforms that are more secure and stable?

14 - Security by correctness, isolation, and randomization >>>> security by virtualization; plus a response to Joanna Rutkowska

The other two popular approaches are Security by Correctness and Security by Obscurity. We don't believe either of these approaches are capable of providing reasonable security today, nor do we believe that they will be capable of doing so in the foreseeable future.

https://doc.qubes-os.org/en/latest/introduction/faq.html#what-about-other-approaches-to-security

With this statement, the developers of Qubes OS admit that their OS is weak, buggy, and insecure by default, and that all its security is based on:

Is Qubes just another Linux distribution? If you really want to call it a distribution, then it's more of a Xen distribution than a Linux one.

That's it. "XenOS" is used to emphasize Xen's central main role in the entire security model.

To save time, I will directly refute Joanna Rutkowska, the "creator" of Qubes OS. https://blog.invisiblethings.org/2008/09/02/three-approaches-to-computer-security.html

Security by Correctness

The assumption here is obvious: if we can produce software that doesn't have bugs (nor any maliciously behaving code), then we don't have security problems at all.

Correct, just like any and all software that is security-focused, it needs code auditing. This goes for Xen, Linux, Fedora and firmwares.

The only problem is that we don't have any tools to make sure that a given code is correct (in terms of implementation, design and ethical behavior).

The same question is applied back to Qubes itself: design quality, implementation quality, and governance all still matter, even in a virtualization-based model.

But if we look at various efforts in computer science, we will notice a lot of effort has been made to achieve Security by Correctness: safe languages, code verifiers (although not sound ones, just heuristic based), developer's education, manual code audit, etc.

And the same goes for the Xen hypervisor and templates. To be reliable they need secure code and developer training. Where did you get that virtualization security eliminates the requirement for secure code? All software needs secure code to be secure. Qubes OS uses the Linux kernel for dom0/NetVM and is vulnerable to the same insecurities.

Microsoft's famous Secure Development Life-cycle is all about Security by Correctness.

False. The life cycle of Windows is due to the greed for money, as it is an operating system with a paid license. In addition to the new features and software that no one asks for with each new version of Windows, which only makes the OS more insecure and adds more attack surface. You don't need to have such a short life cycle and hardware-related (Windows 11 TPM 2.0 requirement) with no additional support this way. There are several other better examples you could use.

The only problem is: all those approaches sometimes work and sometimes do not, sometimes they miss some bug

This applies to any and all software development. There is no way to end this, if you think that isolation BY SOFTWARE, (and even by hypervisor, which is worse) is a solution, then you are being mistaken and contradictory.

and also there are problems that I simple don't believe can be addressed by automatic code verifiers or even safe languages, like e.g. logic/design bugs or deciding on whether a given code behaves maliciously or not (after all this is an ethical problem in many cases, not a computer science problem).

Qubes OS should be evaluated like any other software project: by design quality, implementation quality, and operational outcomes, not by architectural claims alone. Its design choices should not be treated as if they transcend reality or sit above ordinary engineering limits. In the end, Qubes is still software designed by people.

Is there anything to protect me against malicious code, logic/design bugs or wrong implementation of Xen? Adding extra virtualization layers would not solve that root problem; it would mostly add more complexity and more assumptions. And it is also (even more than other OSes) vulnerable to backdoors and supply-chain attacks.

Furthermore, it is only possible to know whether the code behaves maliciously or not through extensive and serious auditing, not only of the lines of code but also of the compilation process and binaries. It is possible for open source software to have invisible backdoors hidden in post-compile binaries, and it is not possible to protect against this except through extensive and in-depth auditing. Ultimately, trust should be greater in the programmer than in the software. And this text concludes that Joanna is not trustworthy.

See about this in Ken Thompson's famous document, Trusting Trust: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

Security by isolation

Simple as it sound, in practice the isolation approach turned out to be very tricky to implement.

No more than virtualization, I promise.

One problem is how to partition the system into meaningful pieces and how to set permissions for each piece. The other problem is implementation - e.g. if we take a contemporary consumer OS, like Vista, Linux or Mac OSX, all of them have monolithic kernels, meaning that a simple bug in any of the kernel components (think: hundreds of 3rd party drivers running there), allows to bypass of the isolation mechanisms provided by the kernel to the rest of the system (process separation, ACLs, etc).

This statement is not absolutely correct. There are kernel-level and user-space mechanisms that limit the impact of bugs. Properly partitioning and defining policies is difficult. Monoliths expand the attack surface, but modern techniques (LSMs, seccomp, KPTI, hardware mitigators, and driver isolation) reduce the likelihood of systemic compromise.

Nowadays, and depending on the operating system, affecting the entire kernel is extremely more difficult; rarely observed in practice compared to past times. Many of the CVEs found in the Linux kernel mainline are not even applicable in real distributions (Ubuntu, OpenSUSE, Fedora) and depend on a range of factors that are not available in operating systems. Not every CVE can be effectively exploited in practice due to operating system mitigations. Finding a bug is one thing; exploiting it is another. That's what mitigations are for, that is what security through randomization is for: preventing bugs from being exploited.

Microkernels may be more secure than a monolithic kernel by design, but it does not necessarily mean that they will be in practice, and it also does not mean that the monolithic kernel will necessarily be insecure. It all depends on how developers treat security, development philosophy and software engineering. Treating virtualization as a solution to insecure code is naive, not to say ignorant.

Kernel exploits in real-world attacks function as post-compromise privilege escalation tools, not as self-sufficient vectors for total compromise.

Obviously the problem is because the kernels are monolithic. Why not implement Security by Isolation on a kernel level then? Well, I would personally love that approach, but the industry simply took another course and decided that monolithic kernels are better than micro-kernels, because it's easier to write the code for them and (arguably) they offer better performance.

Please someone introduce this woman to the technological know-how of kernel hardening and isolation primitives beyond VMs: Namespaces, Capabilities, RCTL, Jails, Zones, Capsicum, Seatbelt, SELinux, AppArmor, vnet, devfs, VFS, Chroot, Smack, Seccomp, LSM hooks, Landlock, SMEP, SMAP, retpoline, NX, DEP, Kernel Page-Table Isolation (KPTI), eBPF/XDP… This woman is crazy if she thinks a virtual machine is the only way to obtain security.

And if the problem is the monolithic kernel, why didn't you make Qubes OS based on a micro-kernel (seL4, L4, HURD, Minix) but on the Linux kernel? Because you don't have the ability to program a kernel or because you think the only way to isolate is through virtual machines? Or both?

I acknowledge that a micro-kernel can be much more secure than a monolithic kernel, however, there is a contradiction in your statements. Qubes uses Xen with a privileged dom0 that runs an outdated and insecure Linux distribution, which controls devices, drivers, and manages other domains (domUs) that are also insecure Linux distributions or even Windows.

Many believe, including myself, that this landscape can be changed by the virtualization technology.

Here we go again.

Thin bare-metal hypervisor, like e.g. Xen, can act like a micro kernel and enforce isolation between other components in the system - e.g. we can move drivers into a separate domain and isolate them from the rest of the system.

You don't need a hypervisor for this, and after all, what isolates the hypervisor? Unlike a kernel, a hypervisor cannot have multiple security implementations that a kernel/micro-kernel can. A hypervisor compromise will cause the same damage as a full kernel compromise, but compromising some part of the operating system on bare metal does not necessarily lead to a full kernel compromise.

Don't let this illusory idea fool you! Xen may be the basis for dom0 and all VMs, but the VMs will be just as vulnerable as the guest OS. Xen doesn't improve the security of a virtual machine and its applications, it just adds more code. Virtualization can separate domains and reduce singular post-compromise effects, but it does not increase (rather reduces) security.

Also, how to make sure that the hypervisor itself is not buggy?

This is the key point of the section: hypervisor trust is a critical assumption that cannot be ignored. What guarantees Xen security?

The code? No, it was written in C/C++/Assembly, so no memory security, and it is also not formally verified. Isolation then? No, a type-1 hypervisor runs on bare metal, has full access to the hardware and control of the devices. Randomization? No. Obscurity? Yes, that is. Most malware is not designed to attack hypervisors, and attackers almost always expect to be on a non-virtualized operating system.

Security by Obscurity (or Security by Randomization)

Finally we have the Security by Obscurity approach that is based on the assumption that we cannot get rid of all the bugs (like in Security by Isolation approach), but at least we can make exploitation of those bugs very hard. So, it's all about making our system unfriendly to the attacker.

Firstly, here she uses the word "obscurity", which, although not wrong, leads to misinterpretation. Security by obscurity also refers to the fact that software is not known, used and therefore attacked. Which is exactly the context in which hypervisors for desktop use fit.

Randomization and exploit mitigations can raise attacker cost in ways that complement virtualization. They are not replaced by virtualization at all.

The obvious disadvantage of this approach is that it doesn't prevent the bugs from being exploited - it only make the meaningful exploitation very hard or even impossible.

From this perspective, making exploitation significantly harder is a practical security benefit, not a weakness. And she says "or even impossible", like this isn't so good. Why do you mean? That is exactly what security is about.

But if one is concerned also about e.g. DoS attacks, then Security by Obscurity will not prevent them in most cases.

Servers are the ones who have to worry about this, you can't open your mouth to talk about it when your operating system is absolutely useless in this area and is made for desktop-only. Also, how can a DoS attack affect the common desktop user? How can this maliciously compromise the operating system? That's a spurious correlation that you just threw up.

If a DoS attack is carried out against your ISP, home network, or online services servers, nothing can be done. The service providers must handle those attacks, not you with Qubes OS or whatever.

Protection against DoS is done with hardware isolation, router filters, load balancers, scrubbing farms at the network edge, CDN/Anycast, BGP ACLs, rate-limiting, and related controls. This is core server infrastructure, which is why desktop-centric virtualization models are not enough by themselves.

Randomization can protect you against some DoS attacks. It's just not the maximum guarantee of security. The greatest and only total guarantor of security is the code. If the code is correct then the behavior of the system will be correct, free of bugs and therefore free of vulnerabilities.

However, only additional hardware and other protections as mentioned previously can really give you strong protection against DoS/DDoS attacks. Virtualization can only help/guarantee quick recovery of servers, not immunity.

The other problem with obfuscating the code is the performance (compiler cannot optimize the code for speed) and maintenance (if we got a crash dump on an obfuscated Windows box, we couldn't count on help from the technical support).

If you want to have security you will have to give up usability. The more security, the less usability. The fewer lines of code, the fewer features and the less attack surface. Furthermore, this last statement is not completely true, OpenBSD is the greatest proof that technical support is completely possible in a system with randomization; After all, OpenBSD randomizes the order of all kernel libraries (Library order randomization), the kernel address (KARL - Kernel Address Randomized Link) and even daemons (httpd, smtpd) all without hindering crash dump analysis.

If you want strong security you will have to trade off something. The problem is that she wants to have security and still have all the benefits of insecure software. That's not how things work, that's another illusion that many people believe.

And you're talking about performance when you previously criticized the monolithic kernel and suggested a microkernel, which has far more performance overheads and management complexity. Once again, you're being contradictory.

Finally there is a problem of proving that the whole scheme is correct and that our obfuscator (or e.g. ASLR engine) doesn't introduce bugs to the generated code and that we will not get random crashes later (that we would be most likely unable to debug, as the code will be obfuscated).

This is not how things work, it is possible to debug and audit the randomization process, making the generated code safe and clean. You can run test suites, preserve symbols in controlled builds, validate invariants, and instruments crashes/repro cases. It's amazing how she doesn't know this, it's basic software engineering. Again, the claim here is that saying randomization necessarily prevents debugging is false.

Other arguments from Joanna Rutkowska: https://blog.invisiblethings.org/2012/09/12/how-is-qubes-os-different-from.html

Many people ask how does Qubes OS differ from other approaches to desktop security. Today I'm trying to answer the most popular questions.

First, if you use Xorg or similar X-based server as your GUI server, and this is what nearly all Linux, and most of the other non-Windows OSes use, then you don't have any form of GUI-level isolation, which is essential for a desktop system.

She's never heard of Wayland, which is impressive given that this was published in 2012 and Wayland was implemented in 2010. It's evidence of her obsolescence. We also currently have XLibre, which supports Xnamespace; it's an excellent project that aims to make X11/Xorg good and secure.

Second, all mainstream desktop OSes, such as Windows, Linux, BSD, even OSX, are all based on a monolithic kernels, which present a significant security problem.

This is because a typical monolithic kernel of a contemporary desktop OS contains tens of millions of lines of code, and to make it worse, most of this code is reachable from (untrusted) applications via all sorts of APIs, making the attack surface on the kernel huge.

First, what operating systems is she talking about? I even understand her saying this about Linux, given that it is just a kernel and that in 2012 Secureblue and many subsequent security implementations on/of Linux did not yet exist, but generalizing BSDs as if they were all the same is tremendously dishonest or poorly reasoned.

OpenBSD had existed for many, many years and apparently she was either unaware of its existence or had never tried to study it to find out the approaches adopted by the system to mitigate or end much of these problems. Furthermore, operating systems such as macOS and other BSDs have already greatly improved their security through kernel-level security, patches and randomization. She does not specify specific vulnerabilities and brings everything together as if it were the one same thing.

To say that monolithic = insecure is intellectual dishonesty. It's necessary to first evaluate the monolithic kernel in question; furthermore, macOS and Windows use hybrid kernels, which, in design, should be more secure than monolithic kernels, but this is not absolutely true in practice, and some monolithic kernels have already demonstrated superior security, such as OpenBSD's own. The only thing that goes through her head besides wind is "virtualization virtualization virtualization." This is a tremendous mental limitation.

She says that monolithic kernels have tens of millions of lines of code, which is not wrong for the most part, but she posits all monolithic kernel operating systems as being the same thing. Currently, the OpenBSD kernel has ~8 million lines of code, and the entire operating system has ~36 million lines of code, compared to the Linux kernel alone which has ~50 million lines of code. At the time she wrote this, the OpenBSD kernel had approximately 3 million lines of code.

But do you know who has the most lines of code? Qubes OS, which for each VM runs an entire operating system, and Fedora from dom0 alone, must already have something close to 1 billion lines of code (approximate value of Debian's LoC nowadays).

She cannot talk about lines of code adding another 660 thousand lines of Xen hypervisor code to the overall system equation. Xen is NOT a microkernel, it does not work like a microkernel, and it will never be as secure as a microkernel. Xen is a type-1 hypervisor that is exposed to being exploited if an attacker exploits the vulnerabilities of the guest OS and seeks paths to the hypervisor, paths that Xen does not try to hide and makes everything worse with paravirtualization.

In Qubes, on the other hand, we use Xen hypervisor to provide security isolation between domains, and Xen is just a few hundred of thousands lines of code.

Isolation maybe, security no. And these "few" lines of code are already much larger than the entire TempleOS. Furthermore, the attack surface of Qubes OS is not just Xen, but everything (devices, management tools, hypercalls etc.), since not even the /boot partition can be encrypted, and what do you do to mitigate this? Nothing, they rely on unreliable proprietary firmware like Intel ME and TPM that only increase the attack surface.

In fact, everything related to hardware can increase the attack surface of Qubes OS, as it is the OS that most requires specific hardware firmware and vendor patches to be minimally secure and stable.

It also doesn't need to provide all sorts of APIs to applications, because the Xen hypervisor is essentially only interested in CPU scheduling, memory management and power management, and very few things beyond that.

Most notably, the Xen hypervisor knows nothing about networking, disk storage, filesystems, USB stacks, etc, as all those tasks are delegated to (often untrusted) service VMs.

Delegating drivers to VMs creates IPC/hypercall/grant surfaces that need checking; many XSAs exploit precisely these interactions. You're living in another reality if you think this reduces the attack surface, it just creates more. Delegating stacks (network, USB, disk) to separate domains reduces the impact of bugs on those stacks, but creates new interfaces and privileges (backends, control domains, grant mappings, hypercalls, emulation) that the hypervisor must mediate and validate. In other words, more complexity, more attack surface. Not to mention Pass‑through.

Practical security depends on the threat model (thing that Qubes OS is described as poor at), updates (thing that Qubes OS is described as poor at), total attack surface (hardware + firmware + software) and not just whether it is monolithic or not. The Qubes architecture reduces a certain type of risk (compartmentalization), but it does not eliminate risk and introduces other surfaces that have already been explored in Xen. Lines of code are no substitute for attack surface analysis; therefore monolithic ≠ inherently insecure, nor Xen ≠ inherently secure. The fact is that the vast majority of vulnerabilities found in Xen are serious (CVSS >= 7.0), and Xen's total XSA count far exceeds KVM and Hyper-V combined over the same period.

While in comparison a minority of vulnerabilities found in operating systems such as OpenBSD, FreeBSD and NetBSD are severe (>7.0). This says a lot: exploiting Xen will almost certainly lead to something much more dangerous than exploiting operating systems with a strong foundation in security. And it's obviously due to the fact that Xen runs at ring 0 (logical ring -1, it has more privileges than a kernel). Vulnerabilities in hypervisors tend to have a more critical impact.

And even with all this, it is still necessary to have the correct hardware so as not to end up running into more problems and increasing the attack surface even further. It is necessary to have support for IOMMU (for adequate insulation), HVM (to avoid PV, which leads to more insecurity, but Qubes only supports full HVM for Windows template), and preferably not even use AMD, as officially only Intel is truly recommended.

After that she criticizes type 2 hypervisors and insecure virtual machines, not completely right but not completely wrong, with the biggest mistake being that Qubes OS is a magical exception, so I'll skip that.

Qubes itself is much more than just the hypervisor.

Finally she admitted the obvious.

Qubes is everything that is needed to build a reasonably secure desktop OS on top of a baremetal hypervisor

Qubes OS is not secure compared to other Linux systems and putting all of this on top of a hypervisor don't make things better.

"everything that is needed to build a reasonably secure desktop OS" And she herself says that she doesn't believe in security mitigations, corrections, randomization and secure programming, this is absolutely contradictory. How can Qubes OS be secure if it goes against everything that guarantees the basis of security in the modern software world?

We think Xen is unique because it combines an elegant architecture (type I, baremetal, hypervisor) with a number of practical features, such as power management, support for Intel VT-d and driver domains, support for both para-virtualizaed, and fully-virtualized VMs

She is redundant when saying "Type 1, baremetal, hypervisor", if it is a type 1 hypervisor then it is baremetal, if it is a baremetal hypervisor then it is type 1, it makes no sense for her to mention this as if it were something exclusive to Xen. She and the Qubes OS devs seem to live in a separate reality, they have isolated themselves from reality through Xen somehow. VMware ESXi and Hyper-V are other examples of type-1 hypervisors that are more secure than Xen.

For instance, KVM, vmm (OpenBSD) and bhyve are kernel modules that effectively convert the host operating system to a type-1 hypervisor. And this is safer than type-1 hypervisors like Xen, as the host kernel can directly control and isolate resources/permissions given to the hypervisor, and therefore have more control over it.

Paravirtualization is also much less secure than full virtualization, as I already said in the first topic of the article. This is literally a negative point of Xen, and Qubes OS only supports full virtualization (through HVM) for Windows templates; everything else is paravirtualized.

How is Qubes better than Google Chrome OS?

First, Chrome OS is not a general purpose OS. Second, it's based on Linux with all its security limitation that are a result of using a monolithic kernel

dom0 and sys-net use which kernel? I'm really starting to believe that she isolated herself from reality by somehow entering Xen.

ChromeOS is more secure than Qubes OS in several practical areas. The system and kernel files live on an immutable partition that apps or malware cannot change. It is sandboxed by design: each browser tab, app, and service runs with isolation and least privilege. It has atomic updates, native user-data encryption, verified boot, and Android/Linux containers. ChromeOS also benefits from the incredible security of the Chromebook, Titan chip and Google's microcontrollers (H1), offering much more security and reliability than generic TPM and Intel ME/AMT. ChromeOS is one of the most secure operating systems in the world, but I still criticize it heavily on privacy grounds and do not recommend it as a privacy-first option.

How is Qubes better than [your favorite commercial military-grade certified secure OS]?

You must have heard about the super secure military-grade, formally verified, 100% certified, and generally unbreakable operating systems made by companies such as Green Hills, Lynx Works, and others. How do they compare to Qubes OS?

Oh, yes. Like the formally verified seL4 microkernel. Or even OpenBSD and FreeBSD, that although they are not "military-grade", are widely used by governments, security agencies and companies in critical infrastructures (firewalls, appliances, servers), and which macOS, iOS, TrueNAS, pfSense/OPNsense and Junos OS are based on.

Really, I have no idea.

Of course not.

15 - Reviewing the developers' arguments

https://doc.qubes-os.org/en/latest/introduction/faq.html

Not all virtual machine software is equal when it comes to security.

Right, even they admit it, let's see what comes next.

You may have used or heard of VMs in relation to software like VirtualBox or VMware Workstation. These are known as Type 2 or hosted hypervisors.

However, the fact that Type 2 hypervisors run under the host OS means that they're really only as secure as the host OS itself. If the host OS is ever compromised, then any VMs it hosts are also effectively compromised.

Absolutely true. This is true for Qubes OS too; if dom0 (or even NetVM) is compromised, it's Game Over. If the Xen hypervisor is compromised via a compromised guest VM, it is also Game Over. Unless the user is able to delete the qubes before the hypervisor is compromised, which is difficult due to what was explained in topic 11 in addition to the serious attack surfaces such as IME and TPM that allow Malware to remain persistent and invisible.

It is intellectual dishonesty on the part of the developers to pretend these statements do not apply to Qubes OS.

By contrast, Qubes uses a Type 1 or bare-metal hypervisor called Xen. Instead of running inside an OS, Type 1 hypervisors run directly on the bare metal of the hardware.

That's true, this makes compromised Type-1 hypervisor generally at least as dangerous as a compromised bare-metal kernel, and often more dangerous, since its output goes directly to the hardware and runs below the kernel permission level (logical ring -1).

This means that an attacker must be capable of subverting the hypervisor itself in order to compromise the entire system, which is vastly more difficult.

Not true and not "vastly more difficult", this doesn't make things harder for the attacker, it makes them easier, since a type 1 hypervisor is the only layer of protection you'll have between the hardware and the guest VM, a single failure in the hypervisor or in the delegation infrastructure compromises everything.

It is not totally true that an attacker need to compromise the Xen hypervisor to compromise the entire system (all VMs/qubes). It is also possible to compromise parts of Qubes OS (typically an AppVM) without compromising the hypervisor, since the native Qubes OS templates are all insecure.

It is also possible, as previously stated, to compromise dom0 through the supply chain (updates, repositories, backdoors in the Fedora ecosystem) or directly through communication with devices (USB), compromise sys-net/NetVM, allowing malware to spread across many Qubes that use that NetVM. All without the user knowing. Disposable qubes won't save you if you don't know you're being attacked.

An operating system based on compartmentalization by virtual machines does not increase your security, instead it just makes you believe in an illusion. My main point is that Qubes OS is not secure, and it is not the most secure desktop operating system. When exchanging strong types of security for virtualization, you lose and gain, but in the case of Qubes OS the loss is greater.

The developers know the danger of placing all your hopes on a hypervisor; after all, they created the border color layout for each VM, indicating the trust levels.

How does Qubes OS compare to using a separate physical machine?

Using a separate physical computer for sensitive activities can certainly be more secure than using one computer with a conventional OS for everything

True. Therefore, do not use Qubes OS, which aims to centralize everything with the vain proposal of compartmentalization.

Physical separation doesn't rely on a hypervisor. (It's very unlikely that an attacker will break out of Qubes' hypervisor, but if one were to manage to do so, one could potentially gain control over the entire system.)

Look how these people don't believe in security through correction, kernel isolation and randomization, but believe in Xen as their god, a tool they didn't even create. They place all their hopes on third-party developers' tools and put them on a pedestal as if they were untouchable; that's poorly reasoned.

Physical separation can be a natural complement to physical security. (For example, you might find it natural to lock your secure laptop in a safe when you take your unsecure laptop out with you.)

That's the smartest thing to do, but you literally recommend the opposite: using a single device for all your life's activities with all your life information, promising that you'll be protected through SOFTWARE compartmentalization.

Physical separation can be cumbersome and expensive, since we may have to obtain and set up a separate physical machine for each security level we need.

I've seen this argument before.

The phrase "application domain security" is a cover-up statement that means "I have already decided to run the multiple things on one box because I am cheap, and I need to invent reasons why I can continue doing so
Theo de Raadt

There's generally no secure way to transfer data between physically separate computers running conventional OSes. (Qubes has a secure inter-VM file transfer system to handle this.)

Have you ever heard of a USB cable? Or better yet, a flash drive? The kind you use to make 100% offline transfers? Or even online services/ applications with end-to-end encryption and/or peer-to-peer? (Magic Wormhole, SFTP/SCP over SSH, Syncthing, croc, etc.).

"No, my cattle, you don't need to use that. We guarantee your security through our inter-VM system, where you can transfer things from a compromised VM with internet access to a clean VM using the same device. Trust your daddy."

Physically separate computers running conventional OSes are still independently vulnerable to most conventional attacks due to their monolithic nature.

And doesn't Qubes OS do that? Each VM uses an entire monolithic kernel operating system. What are you even talking about?

Qubes OS isn't conventional? Using a conventional Fedora/Debian template, using the conventional Linux kernel for dom0 and domUs (or windows, which is worse), using conventional GNU libraries and programs? I know that Qubes OS is unique in that it's a huge mess, but that doesn't make it anything other than just another GNU/Linux system, or multiple entire Systemd/GNU/Linux OSes running at the same time on a single device

With hardware-based partitioning, you can use much more secure operating systems, or even non-secure operating systems, without worrying.

It's amazing how they want to make it seem like using Qubes OS is safer than isolating the workspace with multiple different hardware. The level of idolatry and illusion they are part of is absurd, and they still want to spread the disease among all people.

Malware which can bridge air gaps has existed for several years now and is becoming increasingly common.

What exactly? Unless through physical attack (social engineering, hardware firmware backdoor or exploit) in which Qubes OS is also totally vulnerable, or a compromised router, how is malware going to reach an offline computer? Or even through a physical internet separation? What kind of malware is this? It must be some kind of supernatural being from the Xen's world; I'd like to see an example of malware that could do this, reach air-gapped devices.

If you're talking about advanced attacks performed on theoretical academic research, like: AirHopper/GSMem/USBee - exfiltrate data by modulating electromagnetic emissions or signals via cables to nearby receivers (cell phone/modem). Fansmitter/BitWhisper/DiskFiltration - use varying fan speeds, vibration, or electrical signatures to transmit bits to nearby sensors. IREXF/LEDitGo/xLED - use LED indicators, displays or infrared lights to optically transmit data to cameras/phones. MAGNETO/ODINI - magnetic techniques to exfiltrate data through variations in magnetic fields detectable by nearby devices.

So I'm sorry to inform you, nothing in the world can defeat this other than hardware or additional physical protections like a Faraday Cage. In that threat model, Qubes OS should not be expected to provide any protection at all.

Furthermore, such attacks are carried out in controlled environments and with minimal or zero external interference. Being practically impossible to do in real scenarios. An example of this is the attack discovered in 2024 in which hackers use the friction sound caused by the finger on the cell phone screen to steal fingerprints. https://www.ndss-symposium.org/wp-content/uploads/2024-618-paper.pdf

But this research and simulation was done in a precisely controlled environment, with precise sound capture and noise isolation equipment, and even with all this there is only a 27.9% chance for partial fingerprint and 9.3% for full fingerprint, even in the perfect scenario the chances are ridiculous. In other words, if the attack is carried out against a resident of India, it will be useless, since the deafening and endless noise of vehicle horns would make it completely impossible for the attacker.

These claims are often repeated without enough practical context about how such attacks work in real-world environments. It's worrying to see how they think Qubes OS can protect you from attacks with this level of sophistication. They are not even able to explain why Qubes OS would be a target for this, in what context this would apply, and why Qubes OS can protect you. In short, straight up bullshit.

What is the main concept behind Qubes?

To build security on the Security by Compartmentalization (or Isolation) principle.

"Building security on the principle of hope*, because we cannot guarantee that our compartmentalization will work. And we don't offer other guarantees of protection because we don't even believe in security through a good code, which is the fundamental base of software security."

What about safe languages and formally verified microkernels?

In short: these are non-realistic solutions today. We discuss this in further depth in our Architecture Specification document.

Wow, impressive. But wasn't Xen written in C/Assembly? And it's not formally verified either… So I hate to break it to you, but Qubes OS (Xen) is completely vulnerable to memory management exploits. But I'm glad you don't believe that, after all, what the eyes don't see, the heart doesn't grieve over.

Why does Qubes use virtualization?

We believe that this is currently the only practically viable approach to implementing strong isolation while simultaneously providing compatibility with existing applications and drivers.

The repeated "we believe" framing is criticized here as insufficient without stronger operational evidence. The article also questions compatibility claims given the hardware limitations discussed earlier.

Believing or not in a fact does not make the fact cease to exist, this is a worrying, childish and unprofessional position on the part of developers, and should not be taken seriously

The unfortunate reality right now is that an operating system cannot be secure without a certain minimum number of proprietary closed-source blobs (e.g., CPU microcode updates). A 100% free operating system that excludes all such blobs is vulnerable to known exploits and is therefore unsuitable for any use case where security matters.

That's true. But can non-auditable blobs/firmware can really guarantee your security? In some cases, such as CPU updates, it is valid, but in other cases, such as Intel ME and TPM, it is not, and ends up bringing more bugs, increasing the attack surface.

The OpenBSD, one of the most secure operating systems in the world, is an example of an OS that don't ship proprietary blobs by default in the base system, and hands the decision of whether or not to install proprietary firmware to the user. Also, of course, OpenBSD doesn't rely on processor virtualization technology to be secure.

My criticism is not about having firmware security updates from vendors, but about handing over the entire critical security base of the system to third-party proprietary code (Intel VT-x/VT-d, AMD-V/AMD-Vi), as is the case with Qubes OS and virtual machines. Just because I'm hot doesn't mean I can just throw myself into an erupting volcano. That's the main point here.

A core tenet of the Qubes philosophy is distrust the infrastructure, where the infrastructure refers to things like hosting providers, CDNs, DNS services, package repositories, email servers, PGP keyservers, etc.

This is another perceived inconsistency: Xen, Tor/Whonix, Fedora, Intel/AMD virtualization technology, proprietary firmware, IME and TPM are trusted by the developers. Qubes OS has almost no code of its own and relies entirely on third-party components. If Qubes' philosophy were truly about "distrust the infrastructure", the operating system would have its own hypervisor and other system components (dom0 own OS).

As a project, we focus on securing endpoints instead of attempting to secure the middle (i.e., the infrastructure)

How can you be secure at the endpoint if you have to go through the insecure midpoint first? What kind of nonsense is that? And What about security at the entry point, which is the most important?

since one of our primary goals is to free users from being forced to entrust their security to unknown third parties.

This has to be a joke, they're being ironic, right? I refuse to believe it.

Xen, Fedora + ecosystem (Xorg, systemd, rpm, dnf), Debian + ecosystem, GNU software, Linux + vendor blobs, libvirt, CPU microcode from Intel/AMD, device firmware, hardware features and vendor implementations (VT-x/AMD-V, VT-d/AMD-Vi, SLAT/EPT/RVI, TPM, DMAR/ACPI tables, etc.)

Instead, our aim is for users to be required to trust as few entities as possible (ideally, only themselves and any known persons whom they voluntarily decide to trust).

Like every single piece of third-party software?

We believe that many attempts to make the infrastructure appear trustworthy actually provide only the illusion of security and are ultimately a disservice to real users.

Yes, I agree. I say the same.

Unbelievable, I must live on a reality show.

Although we caution users against placing undue trust in this website because we distrust the infrastructure, we have no objection to enabling website security features when doing so is relatively costless and provides some marginal benefit to website visitors.

So they contradict themselves when it's convenient. Besides, their website is full of JavaScript.

https://doc.qubes-os.org/en/latest/user/templates/templates.html

Each qube has read-only access to the template on which it's based, so if a qube is compromised, it cannot infect its template or any of the other qubes based on that template.

The statement is not true. AppVMs have read-only access to the TemplateVM filesystem, so they cannot directly modify the template files while it is offline. However, if the template is started (for example, to install/update software) while compromised by network access or a malicious binary, the template can become infected; this then spreads to AppVMs that use that template.

RPC services (qrexec), shared folders, or copy/update mechanisms (e.g., updating packages in the template) can be abused by an attacker in an AppVM to perform actions that affect the template or influence qubes that receive data from it. And obviously, exploits in the hypervisor, dom0, or other attack surfaces of Qubes OS can allow privilege escalation to alter templates or other qubes.

Finally, a cloned template does not automatically receive patches from the original template; if an attacker compromises the "source" template before cloning, clones will remain compromised. And they themselves say:

Updates are naturally centralized, since updating a template means that all qubes based on it will automatically use those updates after they're restarted.

And you know what? What guarantees that the developers themselves cannot be compromised by large organizations and provide operating system images or even template updates that have already been maliciously compromised? OpenBSD and other operating systems can protect themselves against this in various ways, but what about Qubes OS?

I considered continuing and refuting the entire Architecture Specification official document, but that would only take up readers' time on many topics already discussed.

My broader intention here is not to challenge the architecture claims point by point, but to show arguments proving the real security of Qubes OS and poor project planning; and also as a bonus refute terrible arguments used to defend it or defend the idea behind it.

16 - Terrible against zero-day attacks

A zero-day (also known as a 0-day) is a vulnerability or security hole in a computer system unknown to its developers or anyone capable of mitigating it. Until the vulnerability is remedied, threat actors can exploit it in a zero-day exploit, or zero-day attack.

https://en.wikipedia.org/wiki/Zero-day_vulnerability

Qubes OS offers good damage control for failures in guest VMs, but its large virtualization-based TCB (Trusted Computing Base) makes it structurally more vulnerable to zero-days attacking privileged components than alternatives with smaller TCB, focus on correctness, and aggressive mitigators (GrapheneOS, OpenBSD, hardened/enterprise Linux distros). Here I will return to some points already discussed previously, but with the sole ultimate objective of proving something else.

Qubes relies on compartmentalization via virtualization (Xen, dom0, VMs with separate privileges) as the main layer of defense, which can be good for reducing the individual impact of known vulnerabilities when the focus of attack is guest VMs and limiting blast radius. But defense against zero‑days depends on the probability of occurrence and the ease with which a failure can escape the box in which it is located; at this point Qubes loses completely.

First, the hypervisor and the set of I/O drivers (firmware, controllers, devices) remain large privileged code written mostly in C/assembly, without formal verification; A zero-day that allows code execution on the hypervisor or DMA (Direct Memory Access) support can escape from a VM to dom0 or the hypervisor itself, compromising all compartments at once. The complexity of the entire Qubes OS together leads to a greater likelihood of bugs and certainly leads to a larger attack surface, especially when it comes to memory management.

If you are thinking at this very moment that: "It's simply not possible, because Xen runs as a kernel on the system, and has only 660 kLoC". So you don't see things as they are, as I do.

Imagine Qubes OS as follows: The hardware turns on and starts the BIOS, the BIOS starts Xen which starts the HAL (Hypervisor Abstraction Layer) and dom0 (the most privileged part of the system, also called AdminVM), dom0 controls each domU/qube (AppVM, NetVM/sys-net, sys-firewall, sys-usb). Each virtual machine is an entire, complete operating system with hundreds of millions to 1 billion or more lines of code, with its own bugs and vulnerabilities. Every single virtual machine (ring 0) has direct access to the Xen hypervisor (logical ring -1) which in turn controls everything including dom0. dom0 does not have access to the internet, but through any domU/qube it is possible to reach Xen and therefore everything, including dom0. Every single part of this gigantic tangle should be seen as additional code, attack surface, possibility of compromise. By using the same device, you're not keeping things isolated like you think you are.

Second, the aggregate attack surface of Qubes is high. In addition to everything said before, there is the kernel(s) of multiple exposed hardware templates and drivers, IPC, hypercalls, grant, backends, control domains, grant mappings, emulation, firmware (TPM, Intel ME, Intel-VT/AMD-V), PCIe/Thunderbolt, unprotected /boot partition and more - more code means more statistical probability of exploitable unknown bugs. Each component is an additional source of zero days; Qubes' "many moving parts" architecture increases the total surface area compared to systems with deliberately smaller TCBs.

A direct attack on the Xen hypervisor through a domU is far from the only way to compromise the entire system. The full-system compromise path are basically any path that can reach dom0, Xen or another trusted service with a bug or overly permissive policy. The big ones are: a Xen escape from an infected domU; a bug in dom0 (outdated Fedora) itself; a bug in qrexec/RPC handling; a bug in the GUI stack; and attacks through device-facing services like network, USB, audio, or storage backends. The file-copy, clipboard, GUI forwarding, and device qubes are the other common routes. None of this are special in the sense of being "safe", they can be just narrower and policy-controlled.

Third, modern mitigations (ASLR, KARL, KPTI, retpoline, SELinux, namespaces, etc.) reduce or obfuscate the kernel's attack surface through isolation and randomization. Taking into account that Qubes OS developers do not believe in security through randomization, kernel mitigations and code correction, this system has nothing that reduces or obfuscates its attack surface, as it does not even have VM spoofing, being completely visible to an attacker.

Fourth, alternatives like GrapheneOS (designed for a hostile environment at the user and mobile kernel level) or OpenBSD (emphasis on code auditing and mitigation by default) reduce the chance of many zero-days occurring and exploited by having smaller stacks, more aggressive hardening policies, and less dependence on proprietary drivers; Linux implementations like Secureblue aim to protect not only against known but also unknown vulnerabilities (the same goes for the other 2 OSes mentioned above), reducing the attack surface, making elevation of privilege exploits much more difficult in principle.

Fifth, Qubes OS is betting that zero-day vulnerabilities will be rare or non-existent, whether in Xen or in all other components/attack surfaces, but the reality is that all new software and firmware vulnerabilities are zero-day; every week, every month dozens or hundreds of zero-day vulnerabilities emerge that require fast and predictable patches, something that the Qubes OS devs do not believe or cannot do (e.g., Xen and everything are developed and maintained by third-parties). So enterprise operating systems like RHEL, AlmaLinux, Rocky Linux, Ubuntu; or operating systems focused on bug and vulnerability correctness like OpenBSD and GrapheneOS are the best at discovering and/or fixing new vulnerabilities, known as zero-days, extremely reducing the likelihood of you being affected by it as an end user.

Finally, the Qubes security model assumes that compartmentalization will be the only and primary security; that's practical, but it's a horrible bet against a world that doesn't act as its developers think. When an effective zero-day arises against the hypervisor, or against privileged subsystems, compartmentalization does not fix or randomize the bug - it simply depends on the bug never existing or not being scalable. In comparison, systems with lower privileged TCB, audited code/smaller attack surface, and mitigations offer greater structural resistance to zero-day attacks.

"Qubes OS allows you to use OpenBSD and all these other operating systems inside qubes", you might say, and no, it doesn't. The only officially supported templates are Fedora, Debian and Windows. There are templates for other OSes maintained by the community, but they are not even actively updated or tested by Qubes OS devs, which further diminishes trust.

In all cases, the Qubes OS Project does not provide updates for these templates.

In addition, these templates may be somewhat less stable, since the Qubes developers do not test them.

https://doc.qubes-os.org/en/latest/user/templates/templates.html

Qubes OS is not even stable by default and yet they offer even more unstable ways to use it? How would this increase security (especially against zero-days)? You can't take this operating system seriously, not if you're like me and value security first.

But even if it were possible this would further increase the surface attack (hypervisor + everything else + guest), the ideal defense is generally to reduce the TCB, not stack it and further increase the complexity and the propensity for bugs, that's not how security works. You can't accumulate more and more code and think that this will give you security, it's totally the opposite. Qubes templates are limited, they run modified versions of OSes and are paravirtualized, all of this is harmful when it comes to security as I said many times before. And again, what protects the hypervisor from the guest operating system?

Qubes OS could improve on this point if it followed the model of a microkernel operating system that has a secure Type-1 hypervisor that manages 1 virtual machine at a time according to the user's wishes, starting with a total of 0 virtual machines by default. There are several microkernels that the Qubes OS development team could use since they are unable to create their own, such as: seL4, L4, MINIX 3, GNU/Mach and others.

Conclusion

Qubes OS is not the best alternative for those seeking security, and without security you cannot maintain long-term anonymity. This OS is for those who want quick and easy control of virtual machines for testing or casual use, and for those willing to trade security for the ability to juggle multiple profiles across work, privacy, and other contexts.

Some criticisms in this article also apply to many other systems, but my claim is that Qubes OS combines all of these concerns at once. The following section presents stronger alternatives for security and isolation.

For anonymity only, Tails or Kicksecure (live USB) are superior; but Whonix is stronger. You can use Whonix in any Linux system, systems that may even be safer than Qubes OS and through the KVM that is a more secure virtualizer than Xen, as previously stated.

Qubes OS's compartmentalization approach achieves useful risk‑reduction for desktop threat models, but its security guarantees are limited by architectural choices. A large privileged hypervisor (Xen) and dom0 form a concentrated TCB (Trusted Computing Base) with ongoing XSAs (Xen Security Advisory), paravirtualized interfaces make VMs easily fingerprintable and increase guest -> hypervisor channels. The system inherits Linux (Fedora/Debian) kernel and driver surface; Qubes also depends on modern CPU microcode and a small set of certified hardware. Disposable qubes can mitigate persistence but do not remove the core high‑privilege attack surface. For high‑assurance server, high threat model or enterprise use where a minimized, auditable TCB, formal hardening, long support windows, and headless management are required - Qubes' desktop‑centric design is a misfit rather than a solution.

An operating system designed by people who don't believe in security through a secure code, bug fixes and mitigations cannot be trusted, because its developer base is not trustworthy.

If your threat model doesn't involve serious and persistent adversaries, powerful organizations, or state actors, Qubes OS might be good for you. If you prioritize compartmentalization over stability and want to manage multiple aspects of your life simultaneously without worrying about servers, zero-day vulnerabilities, or hardware compatibility issues, then Qubes OS might be perfect for you. If your enemy consists of amateur hackers and common police forces, Qubes OS might be sufficient for you. It is appropriate against less capable adversaries, such as script kiddies and opportunistic criminals.

Reality check: Qubes suits solo enthusiasts trading manageability, stability, compatibility, predictability and security for experimental compartmentalization.

Points to consider

I know that VMs bring compartmentalization at the OS level, and that they make many things easier. But user-level sandboxing can be very secure while also being much less complex. An escape from this kind of sandboxing limits an attacker to the user's context; such an escape typically grants only user privileges, not full system control.

There is no such thing as perfect security, much less perfect isolation, but there is security greater than Qubes OS.

Virtual machines are unreliable for security, and you shouldn't trust them either. One of the most reliable hypervisors is OpenBSD's, called vmm.

https://www.openbsd.org/faq/faq16.html

That after much reluctance, even from the creator of OpenBSD, arrived at the system, but created from scratch to be safe, minimalist and focused on absolute security, unlike all other existing hypervisors. And that's why it won't have some features like:

Graphics
Snapshots
Guest SMP support
Hardware passthrough
Live migration across hosts
Live hardware change

Other than that, use KVM, Hyper-V, bhyve or VMware ESXi, they will serve you well and historically they're safer than Xen.

Other criticisms of Qubes OS made by other people that you might want to see, but that doesn't mean I agree 100% with them (and may contradict what was said in this article):

My recommendations instead of Qubes OS

1 - OpenBSD

Simply the most secure Unix-like operating system by default. Created from the beginning in 1995 for first-place security, it is an operating system with the ultimate goal of being the safest in the world. It was a NetBSD fork that until then is already a secure OS, that did not please the paranoid and wise Theo de Raadt (the creator). It is first focused on being safe in the code and then implementing mitigations. The main focus is on fixing bugs before fixing vulnerabilities, because every vulnerability is a bug, but not every bug is a vulnerability.

The OpenBSD project produces a FREE, multi-platform 4.4BSD-based UNIX-like operating system. Our efforts emphasize portability, standardization, correctness, proactive security and integrated cryptography. As an example of the effect OpenBSD has, the popular OpenSSH software comes from OpenBSD.

https://www.openbsd.org

To understand how OpenBSD security and development work, and to learn about all the security protocols and innovations OpenBSD offers in this area: https://www.openbsd.org/security.html

For a better understanding of why OpenBSD is so secure compared to other operating systems, read my other article: Why OpenBSD stands alone

OpenBSD is perfect for servers, after all it was created for that, but it's also a good choice for desktops (I use it myself for daily driving, and I'm writing this article on it).

As I said before, for virtualization, OpenBSD relies on the vmm(4) hypervisor and vmd(8) daemon. Virtual machines can be orchestrated with the vmctl(8) control utility, using configuration files stored in the vm.conf(5) file.

2 - FreeBSD

"FreeBSD is an operating system for a variety of platforms which focuses on features, speed, and stability. Offers advanced networking, performance, security and compatibility features today which are still missing in other operating systems, even some of the best commercial ones."

https://www.freebsd.org

FreeBSD has "jails," something no other Unix-like operating system has. This provides a high level of isolation (through sandboxing), although it is not configured by default. Jails virtualize the access to the file system, the set of users, and the networking subsystem. This allows you to isolate the base system, services, network and Linux binaries in a very secure way, without depending on a hypervisor. You can achieve much more compartmentalization than with Qubes OS and in a much simpler way, without spending many resources. https://docs.freebsd.org/en/books/handbook/jails/

AppJail allows for simpler and more refined control over jails:
- https://appjail.readthedocs.io/en/latest/
- https://appjail.readthedocs.io/en/latest/install/
And for Qubes OS enthusiasts: https://github.com/BawdyAnarchist/quBSD

FreeBSD is an amazing operating system for everything. Servers, desktops, routers, and even gaming-it's actually the best BSD for gaming. You can play Steam games, although with less compatibility than on Linux, but through Wine you can achieve the same game compatibility as Linux. FreeBSD also has compatibility with Linux binaries through Linuxlator, unlike OpenBSD.

For proper installation and post-configuration, READ THE HANDBOOK: https://docs.freebsd.org/en/books/handbook/
For basic hardening and security understanding: https://docs.freebsd.org/en/books/handbook/security/

FreeBSD is not secure by default. Knowledge of its security tools (firewalls, jails, Capsicum, etc.) is necessary.

3 - Gentoo Hardened

This can take several days and maintenance is difficult, but it's the only way to have the highest possible security in a Linux operating system. In addition, it offers absolute minimalism and superior performance to any other existing operating system. Minimalist systems are always the best when it comes to low attack surface, and nothing in the Linux world does this better than Gentoo.

Gentoo can be considered the perfect Linux operating system, but only if you perform a proper installation and configuration. Please, read the manual carefully.

Handbook for a good installation: https://wiki.gentoo.org/wiki/Handbook
Hardening understanding: https://wiki.gentoo.org/wiki/Hardened/FAQ
Hardening guide (can be outdated):

4 - Fedora Secureblue

Secureblue is a hardened Fedora Atomic/Silverblue-style system with an immutable base.

Secureblue is a security-focused desktop and server Linux operating system. It is shipped as a set of OCI bootable container images, which are generated with BlueBuild, using Fedora Atomic Desktop's base images as a starting point.

It includes strong kernel security patches, SELinux enforcing policies, global use of GrapheneOS's hardened_malloc, and mitigations inspired by OpenBSD. This is the most secure Linux desktop by default. https://secureblue.dev

Its main drawback is systemd, but Secureblue's security work outweighs that problem for many users. https://secureblue.dev/features

5 - NetBSD

"NetBSD is a free, fast, secure, and highly portable Unix-like Open Source operating system. It is available for a wide range of platforms, from large-scale servers and powerful desktop systems to handheld and embedded devices."

NetBSD is the best operating system for embedded and IoT devices. It supports an extraordinary range of architectures and hardware, although it is not especially user-friendly as a desktop. https://www.netbsd.org

NetBSD can also be extremely minimalist for those who know how to configure it, more so than any other BSD.

Several security features are available in NetBSD, including IPsec, a homegrown firewall (NPF), a file integrity system (Veriexec), a kernel authorization framework (kauth(9)), disk encryption (CGD), among others. In terms of exploit mitigations, NetBSD supports a good number of modern features: W^X (in both userland and the kernel), Userland ASLR, Kernel ASLR, SMEP, SMAP, and a variety of other internal kernel bug detection features.

To learn more about its security features and hardening:
- https://man.netbsd.org/security.7
- https://wiki.netbsd.org/security

NetBSD has Wine and Linuxlator for natively running many Linux programs (although different from FreeBSD).

6 - Alpine Linux

Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox. It was designed with security in mind. All userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. These proactive security features prevent exploitation of entire classes of zero-day and other vulnerabilities.

https://alpinelinux.org/

Alpine uses musl, BusyBox, and OpenRC instead of the more common glibc, GNU Core Utilities, and systemd stack. That makes it one of the few Linux distributions outside the usual GNU/glibc base, reducing attack surface. Alpine is essentially "Linux if it were good." It is also an excellent and widely used OS for Docker.

Alpine has native support for hardened_malloc, GrapheneOS's malloc implementation. Install it. https://wiki.alpinelinux.org/wiki/Hardened_malloc
For some hardening: https://wiki.alpinelinux.org/wiki/Securing_Alpine_Linux

7 - Artix Linux Hardened

Artix is Arch Linux but good (doesn't have systemd).

Artix uses real init systems, because PID1 must be simple, secure and stable.

https://artixlinux.org

Arch Linux is an independently developed, x86-64 general-purpose GNU/Linux distribution that strives to provide the latest stable versions of most software by following a rolling release model. The default installation is a minimal base system, configured by the user to only add what is purposely required. Arch Linux defines simplicity as without unnecessary additions or modifications.

https://archlinux.org/about

With more than 9.800 packages in the official (Artix) repositories, more than 15.000 in the Arch repositories and more than 115.000 in the AUR, Artix gives you access to a huge amount of up-to-date software. There are also unofficial repositories such as Chaotic-AUR and BlackArch, plus Arch-based ecosystems around EndeavourOS and Manjaro. After Gentoo, this is one of the fastest and most minimal ways to use Linux, which can help reduce attack surface when configured carefully.

Be careful with packages from unofficial repositories such as the AUR. They are community-maintained, and malicious packages have appeared before. Always check the maintainer, creation and update dates, build origin, repository signature, and keyring.

Using this distribution also gives you the Arch Wiki, which is probably the best and most complete documentation in the Linux world. https://wiki.archlinux.org/title/Main_page
For proper hardening (you will take some days):
- https://wiki.archlinux.org/title/Security
- https://madaidans-insecurities.github.io/guides/linux-hardening.html
hardened_malloc is available for download in the AUR, but I don't know if there's a guide on how to configure it in Arch: https://aur.archlinux.org/packages/hardened_malloc

8 - TrueNAS

TrueNAS is a high performance data platform for managing any type of data, delivered through turnkey self-healing storage appliances and expert around-the-clock support.

https://www.truenas.com/

Built around OpenZFS, TrueNAS provides built-in file and block storage services, an OS-level app platform based on Linux containers or FreeBSD jails depending on the edition, and a hypervisor for additional services. It receives steady security updates and benefits from serious developer review.

The products consist of TrueNAS Enterprise and TrueNAS Community Edition. TrueNAS Enterprise is a family of storage appliances, with fully integrated software and hardware, that is sold as a commercial product with enterprise support. TrueNAS Community Edition can be installed for free on commodity x86-64 computers.

If your goal is to manage long-term data in a secure, stable, and reliable way, TrueNAS Community Edition or Enterprise is one of the best options. It is excellent for servers and long-term offline storage. In my opinion, OpenZFS is the best file system for this job: it has strong compression and native encryption. ZFS compression can reduce files by 2x or more, so 500GB of disk storage may hold close to 1TB of data depending on the workload. OpenZFS is native on FreeBSD, available for NetBSD and other Linux, though the Linux integration has its own complications.

9 - Kicksecure

Kicksecure is a free and open-source Linux distribution that aims to provide a highly secure computing environment. It has been developed from the ground up according to a formidable – and time proven – defense in-depth security design. In the default configuration, Kicksecure provides superior layered defenses of protection from many types of Malware.

Kicksecure is a complete computer operating system. Numerous applications come pre-installed with safe defaults which can be used immediately upon installation with minimal user input.

Kicksecure is an extensively reconfigured Debian-based system focused on security, and it is also the base for Whonix. For users who like Debian's usability, this may be the best option. After Secureblue, and probably Alpine, it is one of the most secure Linux distributions by default. https://www.kicksecure.com

10 - RHEL, Rocky Linux and AlmaLinux respectively

These are the best Linux operating systems for businesses that want enterprise security, tested updates, binary compatibility with the RHEL ecosystem, long lifecycles, commercial or third-party support, standards compliance through SELinux, Secure Boot, and FIPS-oriented partners, and predictable operations. They also keep costs controlled while providing a stable experience for advanced users and administrators.

Rocky Linux supports hardened_malloc (experimental): https://sig-security.rocky.page/packages/hardened_malloc

Red Hat: IBM's direction has been terrible for it, and it pushes the Linux world toward centralization. Even so, it is hard to deny that Red Hat's systems and software are excellent and difficult to match in business environments.

11 - Proxmox VE

Proxmox Virtual Environment is a complete open-source platform for enterprise virtualization. With the built-in web interface you can easily manage VMs and containers, software-defined storage and networking, high-availability clustering, and multiple out-of-the-box tools using a single solution.

https://www.proxmox.com

Proxmox VE is the answer for anyone who wants to escape Qubes OS without sacrificing virtualization-based isolation. Built on a Debian base with a hardened Ubuntu LTS kernel, Proxmox uses KVM for full virtualization (HVM) and LXC for lightweight containers; both far more secure than Xen's paravirtualized approach. KVM converts the Linux kernel into a type-1 hypervisor, allowing the host OS to directly control and isolate resources given to VMs.

The security model is simpler: a hardened Debian host running KVM, without Xen's extra paravirtualization surface, grant tables, or hypercall interfaces. Every VM runs fully hardware-virtualized, so no modified paravirtualized templates required. You get stronger isolation without Qubes' compromised security trade-offs.

By design, Proxmox is an enterprise virtualization platform with commercial support, SLAs, and certified hardware compatibility lists. It supports live migration, high-availability clustering (Corosync + Ceph), software-defined networking, professional backup via Proxmox Backup Server (incremental, encrypted, deduplicated), multi-factor authentication (TOTP/WebAuthn/YubiKey), and role-based access control. These are features Qubes OS cannot provide because its entire architecture is desktop-only.

Proxmox is deployed in production environments worldwide, from small businesses to critical infrastructure, and even on the International Space Station. It receives predictable, tested security updates through both free and enterprise subscription channels. It does not need Intel ME or TPM for its security model, and does not "force" users into a tiny set of certified laptops. The attack surface is dramatically smaller than Qubes OS.

For users who want virtualization-based isolation with real enterprise security, commercial support, and a proven track record, Proxmox VE simply does what Qubes OS pretends to do, but securely.

GrapheneOS is a privacy- and security-focused mobile OS with Android app compatibility, developed as a nonprofit open-source project. It is much more reliable and secure than Qubes OS, and more secure than any Linux distribution, but it is only compatible with Google Pixel phones. https://grapheneos.org Profiles can be separated completely, each with its own apps and data, and offline profiles can be created with strong data isolation. That is a safer, simpler, less complex form of isolation than Qubes OS offers.
NixOS has everything to be one of the most secure Linux distribution, if it weren't for that problematic systemd. All the system's default configuration and behavior remains in one file, making the system reproducible, declarative and stable. It also has an incredible repository and package manager. https://nixos.org However, a light shines in this Linux distro: SixOS. "sixos: a nix os without systemd":
- https://inv.nadeko.net/watch?v=gSW3YJ8uyBI
- https://codeberg.org/amjoseph/sixos
But it's still under development? I don't even know how to install it. But in that case, a hardened NixOS would probably be above Secureblue.

For Linux systems that support it, I also recommend installing LKRG (Linux Kernel Runtime Guard) and hardened_malloc:

For a general Linux hardening guide, though it may be outdated:

https://madaidans-insecurities.github.io/guides/linux-hardening.html