So you've heard about Qubes OS , and you're scared to try it. Well, you should be. Qubes OS is not something you can fumble through; there's an upfront research cost, and just because you have a powerful computer, it doesn't mean it'll work. I explain the entire hardware landscape in simple terms.
What is Qubes OS?
A secure operating system built on virtual machines
Qubes OS is a security-focused operating system that uses virtual machines to divide one's digital life into security domains. The OS isolates each domain. If one domain gets compromised, the others remain safe.
Qubes OS is built upon Xen , which is a type-1 hypervisor . Qubes boots Xen first, which in turn boots an administrative domain called "dom0." That's the Linux part you interact with. Qubes further boots many other unprivileged domains called domUs.
I will use the terms "host," "hypervisor," and "guest" throughout the following text. The host is dom0, Xen is the hypervisor, and "guests" refers to domUs.
What are the hardware requirements for Qubes OS?
Plenty of RAM, storage space, and exotic hardware features
Your hardware must support these virtualization technologies:
I'll explain these next.
You should also have the following available hardware resources:
What is hardware virtualization?
Gives guests direct access to the CPU
Hardware virtualization —aka VT-x (Intel) or AMD-V—is a set of CPU instructions that provide guests direct access to the CPU. Before these instructions, computers achieved virtualization entirely in software. This was slow, and hardware virtualization moves guests closer to the hardware.
Both the CPU and BIOS/UEFI must support it. Fortunately, most modern CPUs and motherboards do. However, you may need to enable the option in the BIOS/UEFI.
What is SLAT?
Hardware-assisted address translation for guests
SLAT ( Second-level address translation ) is the umbrella term that describes both these CPU features:
-
EPT: Intel's Extended Page Tables
-
RVI: AMD's Rapid Virtualization Indexing
But what is SLAT? SLAT lets the hardware translate guest memory addresses without the hypervisor.
Modern operating systems use a virtual memory system, which maintains a set of virtual-to-physical memory address mappings in something called a " page table "—each process sees a virtual address space, not a physical one. A guest OS also does this, but without SLAT, the hypervisor must maintain an expensive "shadow" page table (software-tracked mappings). SLAT resolves that problem and takes the hypervisor out of the equation to leverage the hardware ( memory management unit or MMU) directly.
What is the IOMMU?
A virtual memory translator for hardware devices
Justin Duino / How-To Geek
An IOMMU ( I/O Memory Management Unit ) is a virtual memory translator for DMA -enabled hardware devices (like PCIe cards)—just like the MMU does for software.
What is IOMMU for?
Broadly speaking, IOMMU segregates DMA-capable devices—like a Wi-Fi card—from the host. These devices have direct access to memory, so an attack on them may corrupt any part of the system. When using an IOMMU, the device sees a virtual address space instead. The IOMMU ensures all memory access for devices obeys its rules. Consequently, we can assign the device to a guest (aka PCI passthrough ), which can directly use the hardware safely.
In short, guests can receive and use a PCI device directly and more securely because it has restricted access to memory.
How do I tell which hardware supports IOMMU?
In a nutshell, Intel calls this technology "VT-d" and AMD calls it "AMD-Vi." Your CPU, chipset, and BIOS/UEFI must all support it .
This is how you shoot yourself in the foot, so be careful.
To determine hardware compatibility:
-
Verify CPU support: CPU product pages list IOMMU support (VT-d or AMD-Vi)
-
Verify chipset support
-
Verify BIOS/UEFI support: Even with hardware support, software support isn't guaranteed
-
Verify IOMMU groups: Sets of hardware devices that get managed together (VT-d, AMD-Vi)
-
Verify Access Control Services support: Makes the IOMMU more strict
More on IOMMU groups: Every motherboard may have a different IOMMU group configuration. For example, some put all USB controllers into the same group, meaning you must pass all of them through to the same guest. Sometimes, groups can include your GPU, which dom0 needs access to, so you can't pass the group through at all. Access Control Services(ACS) fixes that: it's a CPU and chipset feature that makes the IOMMU stricter and enables sensible group assignments.
Unfortunately, documentation for ACS is scarce, so I recommend relying significantly on other people's experiences. Both the Qubes Hardware Compatibility List (HCL) and Xen Wiki provide the most detailed coverage you'll find on the web. In addition, the Qubes forums or mailing list provide support.
How much RAM does Qubes OS need?
16GB at least; 32GB is the sweet spot
The minimum I'd recommend is 16GB. However, I have heard of people operating with 8GB, but it would be an uncomfortable experience. Ideally, 32GB+.
How much storage does Qubes OS need?
128GB+, but 256GB+ recommended
I've gotten by with 128GB for years, but I would recommend 256GB-1TB.
Every guest (aka AppVM) in Qubes OS maintains private storage, which your personal (home directory) files live in. If you install several distros (to serve as the base OS for your guests), perform updates, install Docker images, and accumulate large caches of temporary files, you can run out of space quickly.
Does Qubes OS have GPU support for guests?
No, not officially, but yes, with plenty of tears
No. Qubes does not directly provide GPU support for guest domains (only the host), which means guest applications (like browsers) cannot use hardware acceleration. However, the team is developing paravirtualized GPU support through the emerging VirtIO native contexts , which show near-native speeds for KVM .
But if you cannot wait that long, it's possible (through a highly technical endeavor) to make SR-IOV work on Qubes . SR-IOV is much like—and dependent upon—IOMMU, except instead of passing through an entire GPU to a guest, you pass through a "virtual function," which is a mere slice of the GPU. You can assign each slice to one guest at a time, but a GPU provides multiple. As a result, multiple guests can use full GPU acceleration, securely isolated from other guests and the host.
Qubes doesn't officially support SR-IOV, and it may require recompilation of the kernel. It may also involve many hours of testing and debugging.
SR-IOV depends on IOMMU (VT-d, AMD-Vi), and so the chipset, CPU, and BIOS all matter. Only modern consumer chipsets will support SR-IOV, and the GPU itself must expose virtual functions—something most consumer cards don't do (but a few do).
You may look at the hardware specs and think your computer can handle it, but that's the straightforward part. The hard part is matching all the other variables. IOMMU is challenging, and it's a bit of a crapshoot if someone else hasn't tried and tested the hardware already. Your powerful computer may have an Achilles' heel through poor UEFI implementation or lack of hardware support for obscure tech like IOMMU, ACS, or SR-IOV (which consumer hardware often does).
If you already have the hardware, it can't hurt to try, but be careful if you're purchasing new hardware first. Intel Xeon processors often have good virtualization features (including good ACS and IOMMU support); some workstation ThinkPad models come with them. It's usually a game of finding the right hardware, not necessarily the fastest.
