Canonical Frees Confidential Computing From Ubuntu’s Two-Year LTS Wait

Canonical has introduced a new update model for Ubuntu’s virtualization stack that lets confidential computing support move faster than the underlying LTS release cycle. In a blog post published July 27, 2026, Canonical’s Ijlal Loutfi detailed a virtualization Hardware Enablement (HWE) stack for Ubuntu 26.04 LTS (“Resolute Raccoon”) that gives administrators an opt-in path to newer QEMU, libvirt, and firmware versions every six months, without leaving the LTS release.

Why Confidential Computing Outgrew Ubuntu’s LTS Model

Ubuntu LTS releases exist to give organizations a stable, predictable base with long-term security maintenance, typically locked to whatever component versions shipped at release time until the next LTS arrives two years later. That works for most software, but confidential computing features do not land in one piece. A CPU vendor can add a capability before the kernel exposes an interface for it, before QEMU can model it, before libvirt can configure it without hand-written QEMU command lines, and before firmware such as OVMF can boot a confidential guest correctly. As Loutfi put it, “only when these pieces line up does the feature actually become usable.”

Ubuntu already ran a Hardware Enablement model for the kernel, covering KVM support and the low-level interfaces confidential VMs depend on. But the kernel is only one layer: if it moves ahead while QEMU, libvirt, or firmware lag behind, users stay blocked from a capability the kernel already supports. That gap has shown up in practice before. According to Ubuntu’s own server documentation, guest-side support for running confidential VMs under AMD SEV-SNP arrived with Ubuntu 24.04 LTS, but the host-side enablement needed to actually run those guests, QEMU and OVMF support, did not land until Ubuntu 25.04, a full year later.

What’s in the New HWE Stack

Starting with Ubuntu 26.04 LTS, Canonical is shipping four HWE-tracked components, according to Ubuntu’s virtualization documentation:

• qemu-hwe: hypervisor and system emulation
• libvirt-hwe: virtualization management library and tools
• edk2-hwe: UEFI firmware, including OVMF
• seabios-hwe: BIOS firmware for compatibility

A new helper package, ubuntu-helper-virt-hwe, installs the ubuntu_virt_helper script so administrators can inspect and switch the installed variant as a single unit rather than upgrading individual packages by hand. That matters because, as the Ubuntu blog post notes, virtualization “is not one package; it is a set of components that need to move together,” and switching only one “can leave a system in an incomplete or inconsistent state.”

The stack is opt-in. A fresh install of qemu-system-x86 still pulls in the base virtualization packages by default; moving to the HWE variant is an explicit action, and existing systems are unaffected unless an administrator chooses otherwise. For the first two years of the Ubuntu 26.04 LTS lifecycle, Canonical will refresh the HWE stack every six months to match upstream versions already validated in Ubuntu’s interim releases before they reach LTS users.

The Hardware This Is Meant to Keep Up With

AMD’s confidential computing protection is a layered progression, according to Ubuntu’s documentation. Secure Memory Encryption (SME) is the foundation, providing transparent encryption of host and guest memory against physical attacks, though the hypervisor can still read VM contents. Secure Encrypted Virtualization (SEV) extends that by giving each VM its own encryption key. SEV-ES adds encryption of the VM’s CPU registers and execution state. SEV-SNP, the newest and most comprehensive tier, adds memory integrity checking: it “prevents the hypervisor from manipulating the memory mapping and encrypts guest memory pages with per-page authentication tags, ensuring data integrity and preventing rollback attacks,” and it requires EPYC processors from the “Milan” generation onward.

Intel’s approach, Trust Domain Extensions (TDX), works differently. Per the Linux kernel’s TDX documentation, a CPU-attested “TDX module” runs inside an isolated CPU range and manages protected guests, called Trust Domains, isolating guest register state and encrypting guest memory so that confidential VMs are protected “from the host and physical attacks.”

What Still Has to Land

Canonical’s post lists several confidential computing features still working their way through upstream development: live migration for confidential VMs, trusted device assignment, accelerator support, improved attestation flows, and the TEE Device Interface Security Protocol (TDISP) for confidential I/O. Each will need coordinated changes across the kernel, KVM, QEMU, libvirt, and OVMF before it is usable, the same multi-layer dependency chain that made the current HWE stack necessary in the first place.

Canonical is pitching the rolling stack at users who cannot fully leave LTS but also cannot wait two years for new hardware support: confidential inference and accelerator workloads, private and sovereign cloud platforms, and regulated environments in financial services and other sensitive-data processing that need both a stable base and current hardware capabilities.