KVM Hardening Checklist
An interactive checklist of 22 established controls for securing a KVM / QEMU / libvirt host — from sVirt confinement and the seccomp sandbox to a minimal device model, CPU side-channel mitigations, KSM, network isolation and least-privilege access. Check items off, watch progress per section, and copy or export the whole list as Markdown. Everything runs in your browser; progress is saved locally.
Host OS & confinement
0/3 · 0%Keep the host minimal and confine every VM process with a mandatory access control (MAC) policy.
QEMU & device model
0/6 · 0%Shrink and sandbox the emulated hardware — the primary guest-to-host attack surface.
CPU & side-channel
0/4 · 0%Apply microarchitectural mitigations and limit what the silicon shares between guests.
Memory
0/2 · 0%Avoid cross-tenant memory sharing that enables dedup side channels.
Network isolation
0/2 · 0%Separate tenants at layer 2 and filter spoofed guest traffic.
Access control
0/3 · 0%Least privilege for /dev/kvm, libvirt and the management plane.
Patching & monitoring
0/2 · 0%Patch the whole stack on a cadence and audit access to the virtualization layer.
An educational hardening checklist of established KVM/QEMU/libvirt controls — not an audit, certification or configuration guarantee. Commands and config keys are standard defaults; confirm each against the current documentation for your distribution and versions, and test changes before applying them in production. Your progress is saved only in this browser.
What this tool is
- A free, interactive checklist of 22 established KVM/QEMU/libvirt hardening controls, grouped into 7 areas — check items off and track your progress per section and overall.
- Every control is real and widely documented: sVirt/SELinux or AppArmor confinement, non-root per-VM QEMU, the seccomp sandbox (-sandbox on), a minimal device model (no floppy → VENOM), q35/microvm machines, CPU side-channel mitigations, disabling KSM for multi-tenant hosts, per-tenant network isolation, least-privilege libvirt and /dev/kvm, and patch/audit cadence.
- The real guest-to-host attack surface is the QEMU device-emulation code and the shared host kernel — not the small KVM module — so most controls shrink or sandbox that surface.
- Each item explains why it matters and gives a concrete command or config hint (e.g. seccomp_sandbox = 1, kvm-intel.nested=0, systemctl disable ksm).
- Everything runs in your browser; progress is saved locally and you can copy or export the whole checklist as Markdown. It is an educational aid, not an audit or certification.
The KVM / QEMU trust boundary
KVM itself is a small Linux kernel module that uses hardware virtualization (Intel VT-x / AMD-V) to run guest code directly on the CPU. By itself it does very little — it is the user-space VMM, almost always QEMU, that provides the guest's virtual devices: NICs, disks, graphics, controllers. That device-emulation code is the real guest-to-host attack surface: each emulated device is C code parsing input that a hostile guest fully controls. Hardening KVM is therefore mostly about shrinking and sandboxing that surface, and about protecting the shared host kernel and CPU that sit beneath every guest.
The textbook lesson is VENOM (CVE-2015-3456): a buffer overflow in QEMU's virtual floppy controller that was reachable even when no floppy was attached, and that shipped in every VMM embedding that QEMU code. It is why "remove unused emulated devices", "use a minimal q35/microvm machine" and "run QEMU non-root under a seccomp sandbox with sVirt" are foundational. Beneath the device model, cross-VM CPU side channels — L1TF/Foreshadow (CVE-2018-3646), MDS, the Spectre/Meltdown family — and memory-dedup channels (KSM) can leak data between tenants, which is why host-kernel mitigations, SMT/core-scheduling decisions and disabling KSM for multi-tenant hosts all belong on the list.
How to use it: work through each section, checking controls you have in place. The commands and config keys are standard defaults — always confirm them against the current documentation for your distro and versions, and test before applying in production. This is a planning and self-assessment aid, not an audit or a guarantee.
Frequently asked questions
What is the most important KVM hardening control?
Mandatory access control confinement of the VM process — sVirt (SELinux) or AppArmor — is the single most important containment layer. It labels each QEMU process and its disk images so that even a fully compromised QEMU can only touch its own resources, not other VMs or the host. libvirt enables it by default; keep SELinux in enforcing mode and confirm security_driver in qemu.conf. After that, the highest-value controls are running QEMU non-root with a per-VM uid, enabling the seccomp sandbox, and removing unused emulated devices.
Why does removing the virtual floppy (and other devices) matter?
Every emulated device is C code in QEMU that parses guest-controlled input, and that is where most guest-to-host escapes have been found. The canonical example is VENOM (CVE-2015-3456): a buffer overflow in QEMU’s virtual floppy disk controller that was reachable even when no floppy drive was configured for the guest. Because that code shipped in every VMM embedding QEMU, a single device-model bug affected KVM, Xen and others at once. Stripping the guest hardware list to the minimum the workload needs — no floppy, no unused legacy controllers, preferring virtio and a q35 or microvm machine model — directly removes attack surface.
What host-kernel and CPU mitigations should a KVM host have?
Keep the kernel’s microarchitectural mitigations enabled — do not boot with mitigations=off — because side-channel classes like L1TF/Foreshadow (CVE-2018-3646), MDS and the Spectre/Meltdown family can leak data across VM boundaries on shared hardware. For hosts running mutually untrusted tenants, also disable SMT (hyper-threading) or use core scheduling so two tenants never share a physical core, disable nested virtualization if guests do not need it (kvm-intel.nested=0 / kvm-amd.nested=0), and keep CPU microcode updated. Review /sys/devices/system/cpu/vulnerabilities/* to see the host’s current status.
Should I disable KSM on a KVM host?
Disable Kernel Same-page Merging (KSM) when the host runs mutually untrusted tenants. KSM deduplicates identical memory pages across VMs to save RAM, but that sharing creates a measurable timing side channel that can reveal whether another tenant holds specific data. Turn it off with systemctl disable --now ksm ksmtuned (or echo 0 > /sys/kernel/mm/ksm/run). It is reasonable to keep KSM enabled only within a single trust domain where cross-VM leakage is not a concern.