Confidential VMs force KVM to pick sides on attestation and trust
Arm CCA realms and TDX quote plumbing are no longer vendor demos; they are mainline ABI fights over roots of trust, hardware gaps, and how much attestation the hypervisor should own.
Confidential computing is no longer waiting politely outside the kernel tree. The argument now is not whether KVM should host protected guests, but which pieces of the trust model become frozen ABI, which stay in firmware or userspace, and who eats the cost when silicon and crypto both refuse to stand still.
Two threads make that shift concrete at once. On arm64, Steven Price’s large KVM series for the Arm Confidential Compute Architecture is again in circulation as a combined stack: firmware wrappers for the Realm Management Monitor plus the KVM path to create, populate, and run Realm VMs. On x86, a seemingly narrow TDX guest change (make the Quote buffer size dynamic) has reopened a wider fight over attestation scoping, DICE evidence, host contention, and whether new plumbing belongs in the guest driver or in KVM. Read together, they show confidential VMs pushing the hypervisor into politics it used to leave to vendor SDKs: hardware roots of trust, migration shaped evidence, and the boundary between guest measurement and host controlled quote services.
Price’s cover letter is blunt about the goal. The work “adds support for running protected VMs using KVM under the Arm Confidential Compute Architecture (CCA), including the firmware support needed to communicate with the Realm Management Monitor (RMM).” The RMM interface is not a thin ioctl gloss. Version 2.0 style Stateful RMI Operations let the monitor split work across SMC calls, handle interrupts mid operation, and request host memory dynamically instead of demanding auxiliary granules up front. That design pulls KVM into a tighter dance with firmware: discover and configure the RMM, keep GPT entries coherent for host memory, and expose Realm creation only when the platform can actually run one safely.
Hardware is already arguing back. KVM had been prepared to advertise Realm support whenever the RMM was present, then create VMs with KVM_VM_TYPE_ARM_REALM on that basis. Price tightened that after review of interrupt controller traps. On CPUs that lack ICH_HCR_EL2.TDIR, normal guests can fall back to ICH_HCR_EL2.TC so ICC_DIR_EL1 still traps through the common GICv3 path. “Realms cannot rely on the normal hyp-side trap handling for that fallback,” he wrote, “so advertising RMI support on such systems lets userspace create a realm that cannot safely run.” The proposed rule is hard: require ARM64_HAS_ICH_HCR_EL2_TDIR before KVM_CAP_ARM_RMI or Realm VM types, while leaving ordinary VM creation alone on systems that still need the TC workaround.
That is not a paper CPU footnote. Kohei Enju reported that Fujitsu’s MONAKA silicon implements CCA (FEAT_RME) without FEAT_GICv3_TDIR, and stressed that “this is not a hacked-up test system.” Real hardware is arriving with Realms and without the interrupt feature KVM wants to treat as a gate. The upstream choice then becomes a product choice: refuse Realms on otherwise CCA capable machines, invent a Realm safe trap story that does not exist yet, or weaken the advertisement rules and push failure into guest bring up. Either way, confidential VM support stops being a pure feature bit and becomes a statement about which incomplete platforms the ABI will bless.
Adjacent arm64 review traffic shows the same class of problem below the marketing line. Delegated guest pages, linear map visibility, and fault injection paths collide with ordinary kernel helpers such as load_unaligned_zeropad() during path walk. Catalin Marinas noted that if delegated pages stay mapped in the linear map, fixup_exception() is needed and a warning is undesirable; Will Deacon pointed at the alternative of unmapping guest memory from the linear map for guest_memfd style flows. Protected guests do not only add a new VM type. They force the host to decide which of its own accidental accesses remain recoverable, and which become policy about unmapping and SEA versus GPF behavior. pKVM and Gunyah already diverged here in the field; mainline CCA work has to pick a story that does not paper over EL1/EL2 map mismatches.
The TDX side looks smaller until the trust boundary is named. Peter Fang’s series replaces a fixed Quote buffer with a size queried from newer TDX module metadata, keeping a 128 KB fallback for older modules. The motivation is blunt: “The fixed-size Quote buffer approach is not sustainable. As cryptographic algorithms evolve, TD Quote sizes also grow.” DICE layered evidence already pushed buffers up; post quantum certificate chains are described as roughly an order of magnitude larger still. A Quote is a platform signed attestation structure carried through a shared guest/host buffer with a GHCI defined header. If that buffer is a constant, every crypto transition becomes another guest driver break.
Reviewers immediately asked why the host is in the path at all, and what “TD scoped” quoting is for. Rick Edgecombe’s defense is operational as much as cryptographic: avoid doing the quote as a pure TDG call so the host can control contention on shared quote resources, keep userspace free to choose a quoter, and preserve the existing exit shaped flow. Artem Bityutskiy pressed whether attestation is a one off or a pattern of “many TDs compete for a shared TDX capability, VMM needs to be involved to handle fairness,” and the host priority bit discussion showed how crude today’s contention tools are: host priority can lock guests out if userspace never retries, which is fairness between host and guest more than fairness among TDs.
Sean Christopherson challenged the ABI direction directly. Freezing the guest TD report size so evidence accretes in the quote, then solving growth with KVM involved host uAPI, drew a sharp line: “So instead of adding new uAPI for the guest, TDX adds new uAPI to KVM? That's not a very compelling argument.” On the claim that report size churn is painful, he asked the practical question: “Who cares? And I mean that literally, i.e. "who" as in "what chunk of code is negatively affected if the TD report size changes".” Variable sized GET style ioctls are ordinary; a new TDX_CMD_GET_REPORT0_2 style command is an option. Terminology slipped too. Structures that reuse report layout without TD information are not reports about a TD, and Christopherson insisted the naming stop blurring that fact.
Edgecombe conceded that “freezing of the TD report size is only a very minor benefit” and mostly a tie breaker, while still holding the host managed contention point. Fang later argued the dynamic buffer series can move again because quote growth is real “regardless of how we end up getting them,” DICE or otherwise. Edgecombe agreed on that narrow claim. What remains unsettled is the larger design: clean separation with TD evidence in the report and the quote limited to signatures and trust material, versus a per TD quote that absorbs expanding evidence because the report ioctl is already full and host scheduling wants a hand on the gate.
Across both architectures the through line is the same. Confidential computing pulls firmware monitors, platform keys, interrupt and memory map corner cases, and attestation formats into KVM’s ABI surface. Arm is deciding when a Realm is honest to advertise, and how much host kernel fault behavior must change to keep delegated memory from turning into surprising aborts. Intel paths are deciding whether attestation expansion is a guest problem, a KVM problem, or a userspace quoter problem, and whether migration and multi TD fairness justify host ownership of quote production. Neither debate has a tidy winner. CCA still has to reconcile production silicon that ships RME without TDIR, RMM stateful memory behavior, and linear map policy. TDX still has to reconcile PQC sized quotes, DICE evidence placement, and Christopherson’s demand that KVM not become the default escape hatch for guest uAPI regret.
What is fixed is the venue. These are no longer slide deck trust models. They are mainline questions about which hardware gaps block a capability bit, which buffer sizes become ioctl contracts, and how much of the root of trust story the hypervisor is willing to own once guests can be measured, quoted, and moved.