Virtualization on Le Site de François

Confidential VM (CVM)

Mon, 01 Jan 0001 00:00:00 +0000

A Confidential VM (CVM) is a virtual machine in which the guest’s memory contents, CPU register state, and execution flow are hardware-encrypted and isolated from everything outside it: the hypervisor, the host operating system, the cloud operator, other tenants, and anyone with physical access to the machine. The isolation is enforced not by software policy but by the CPU itself, using TEE technology — Intel TDX, AMD SEV-SNP, or Arm CCA — so that no amount of privilege on the host side grants access to the guest’s private state. A CVM is the VM-granularity equivalent of what SGX enclaves provide at the process level: the key difference is that a CVM requires no application changes, making it the practical path for lifting existing workloads into a confidential computing environment.

Kata Containers

Mon, 01 Jan 0001 00:00:00 +0000

Kata Containers is an Open Infrastructure Foundation (OpenInfra Foundation) project that replaces the Linux namespace and cgroup isolation of a conventional container runtime with a full VM boundary, while remaining entirely compatible with the OCI runtime specification and the Kubernetes CRI. From the perspective of containerd, CRI-O, or the Kubernetes kubelet, a Kata pod is indistinguishable from a runc or crun pod — the same API calls, the same lifecycle verbs, the same pod spec — but instead of calling clone() to create a new namespace, Kata starts a lightweight virtual machine. The workload runs inside that VM with its own kernel, its own device model, and a hardware-enforced isolation boundary between itself and the host kernel. The premise is that Linux namespaces, while convenient, share the same kernel as the host: a kernel vulnerability exploitable from inside a container can affect the host and every other container running on the same node. A VM boundary means that even a full guest kernel compromise cannot directly affect the host.

KubeVirt

Mon, 01 Jan 0001 00:00:00 +0000

KubeVirt is a CNCF project that makes Kubernetes a native hypervisor management plane, allowing KVM virtual machines to be declared, scheduled, and operated through the Kubernetes API without a separate virtualisation management layer. The motivating use case is organisational convergence: teams running a mix of legacy VM workloads and modern containerised services no longer need two separate platforms (an OpenStack or vSphere cluster for VMs, a Kubernetes cluster for containers) with separate networking, storage, RBAC, and CI/CD integration. With KubeVirt, both workload types live in the same cluster, share the same kubectl and GitOps tooling, and are subject to the same scheduling, resource quota, and network policy primitives. KubeVirt reached 1.0 in 2023 and is the engine behind Red Hat OpenShift Virtualization, the downstream product used by organisations migrating away from VMware.

KVM/QEMU

Mon, 01 Jan 0001 00:00:00 +0000

KVM (Kernel-based Virtual Machine) and QEMU (Quick Emulator) solve different halves of the same problem and are almost always used together. KVM is a Linux kernel module that turns the kernel into a hypervisor: with Intel VT-x or AMD-V, guest CPUs run on real hardware at near-native speed and guest memory is managed through extended page tables. KVM has no device model of its own — no disk, network, or firmware emulation. QEMU supplies that in userspace (virtio, USB, VGA, ACPI) and controls KVM by issuing ioctl calls on /dev/kvm — creating VMs, mapping memory, running vCPUs via KVM_RUN — while QMP exposes external management over a Unix socket. libvirt, originally from Red Hat, sits above both: it translates domain XML into QEMU command lines and lifecycle operations. The stack is the default on Linux: RHEL ships qemu-kvm, OpenShift Virtualization runs KubeVirt (virt-launcher → libvirt → QEMU), and OpenShift Sandboxed Containers uses Kata Containers with the same hypervisor to isolate pods in micro-VMs.

SEV-SNP (AMD Secure Encrypted Virtualization – Secure Nested Paging)

Mon, 01 Jan 0001 00:00:00 +0000

SEV-SNP is AMD’s third-generation confidential computing technology for EPYC processors, and the generation in production use across major cloud providers (AWS, Google Cloud) and Linux distributions today. It builds on two predecessors: SEV (2016), which encrypted each VM’s memory with a per-VM AES key managed by the AMD Secure Processor, and SEV-ES (2017), which additionally encrypted CPU register state on VM exit to prevent the hypervisor from reading guest execution state. SEV-SNP’s defining addition is memory integrity: using Secure Nested Paging, the firmware enforces that if a guest can read an encrypted memory location, the value returned must be exactly what the guest last wrote there — closing the replay, remap, and memory aliasing attacks that made earlier generations insufficient for a fully untrusted hypervisor threat model.

SR-IOV

Mon, 01 Jan 0001 00:00:00 +0000

SR-IOV (Single Root I/O Virtualisation) is a PCI-SIG specification that lets one physical PCIe device (typically a NIC or accelerator) expose multiple lightweight Virtual Functions (VFs) — each assignable directly to a VM or container — while a Physical Function (PF) remains for management and global configuration. VFs bypass much of the hypervisor’s software switching path, delivering lower latency, higher throughput, and more deterministic behaviour than paravirtualised virtio alone — properties valued in telco NFV (vEPC, vRAN CU/DU, firewall, DPI) and in cloud-native packet workloads on Kubernetes.

TCB (Trusted Computing Base)

Mon, 01 Jan 0001 00:00:00 +0000

The Trusted Computing Base (TCB) is everything you must trust for your security guarantees to hold: CPU and firmware, the host kernel, the hypervisor, the container runtime, the kubelet, identity and secrets infrastructure, and any management plane that can change workload configuration. If any component in the TCB is buggy, misconfigured, or controlled by an adversary, the whole security argument fails — regardless of how well the application itself is written. The classic design principle is TCB minimisation: keep this set as small as possible, because every added component is another place where a flaw can void your policy. “Trusted” here does not mean “trustworthy in practice”; it means “assumed correct by the security model.”

TDX (Intel Trust Domain Extensions)

Mon, 01 Jan 0001 00:00:00 +0000

Intel Trust Domain Extensions (TDX) is a confidential computing technology built into Intel CPUs that allows entire virtual machines — called Trust Domains (TDs) — to run with hardware-enforced isolation from the host hypervisor, VMM, and any other software on the platform, including privileged system software with administrative access. Unlike SGX, which protects small application-level enclaves, TDX operates at the VM level, making it suitable for lifting existing workloads into a confidential environment without significant code changes.