KVM planes head for takeoff [LWN.net]
LWN<br>.net<br>News from the source
Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments
LWN FAQ<br>Write for us
Edition Return to the Front page
User:<br>Password: |
Log in /<br>Subscribe /<br>Register
KVM planes head for takeoff
Did you know...?
LWN.net is a subscriber-supported publication; we rely on subscribers<br>to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the<br>net.
By Jonathan Corbet<br>August 11, 2026
Virtualization places a guest system into a separate security domain,<br>typically with fewer privileges than software running directly on the host.<br>Increasingly, there is interest in creating multiple security domains<br>within a single virtualized system as well. CPU vendors (and software<br>vendors too) are implementing solutions; each of which, of course, is<br>different from all of the others. KVM planes, currently under development<br>by Jörg Rödel, Paolo Bonzini, and others in the KVM community, is an<br>attempt to provide an abstraction layer that makes all of these features<br>available on Linux systems; it is not a small task.
When an operating-system kernel launches within a virtual machine, it<br>typically has full access to all aspects of that machine. Interest in<br>confidential computing, though, is driving efforts to split up that access.<br>So, for example, a virtual machine may have a smaller kernel within it that<br>is charged with implementing a trusted platform module (TPM) in software; if<br>the virtual machine as a whole can manipulate that TPM, its results cannot<br>be trusted. But if the TPM has its own range of memory that only it can<br>access (and which might be encrypted to strengthen that protection) and its<br>CPU state cannot be changed from the containing VM, then it should be<br>secure — until somebody inevitably figures out a way to break that<br>security, of course.
Many processor families have features meant to support this sort of secure<br>enclave. Arm CPUs can provide Realm<br>Planes, which have varying levels of privilege regarding memory<br>protections, exception handling, and more. AMD's SEV-SNP<br>secure-virtualization feature can support up to four virtual<br>machine privilege levels with similar sorts of controls, and Intel's TDX<br>implements partitions.<br>Microsoft's Hyper-V<br>hypervisor has the concept of Virtual<br>Trust Levels, which supports a secure kernel and "trustlets" that carry<br>out security-related operations. In the end, each of these features works<br>toward the same goal, and systems developers would naturally prefer to not<br>have to worry about the details of the specific CPU their code is running on<br>today.
The proposed answer to this need is KVM planes, the patches for which were last posted by Rödel<br>in June. According to this documentation<br>patch, the "planes" name was chosen this way: "Ah, and because x86<br>has three names for it and Arm has one, choose the Arm name for all<br>architectures to avoid bikeshedding and to displease everyone---including<br>the KVM/arm64 folks, probably". This posting derives from an earlier<br>implementation posted by Bonzini in 2025.
A plane encapsulates a privilege level implemented by the processor or<br>hypervisor; one plane would represent an SEV-SNP virtual machine privilege<br>level, a TDX partition, a Hyper-V virtual trust level or, yes, an Arm Realm<br>Plane. All planes share the same address space and many processor<br>resources, but have their own copies of the CPU register set and some other<br>resources. Switching between planes (to allow a lower-privileged plane to<br>request a service from a more-privileged one) is handled with calls back<br>into the hypervisor. Each plane is represented by an integer ID, with no<br>defined relationship between IDs and relative privilege level.
A virtual machine, at creation, will have a single plane, running in the<br>most privileged mode. There is a new KVM ioctl()<br>(KVM_CREATE_PLANE) to create a new plane; it returns a file<br>descriptor that can be used to control that plane. Virtual CPUs are<br>contained within planes, so each created plane must have at least one<br>virtual CPU added to it for it to be useful. The virtual CPUs contained<br>within a plane must be a subset of those configured for any more-privileged<br>planes.
A plane at a given privilege level can generally set the rules for planes<br>with lower privilege. A plane cannot, however, grant any privileges (such<br>as access to a specific range of memory) that it does not possess itself.<br>Certain privileges, such as the ability to control the injection and<br>handling of interrupts, may be restricted to the most-privileged plane.
For any given virtual CPU, only one plane can be executing at any given<br>time. The policy built into the posted patch set is that, if more than one<br>plane is runnable, the lowest-numbered of them is run. That is a somewhat<br>interesting choice, since the above-linked documentation patch states<br>clearly that "KVM is currently agnostic to whether low ids are more or<br>less privileged"; arguably, the...