virtCCA: Measured Boot and Attestation Demystified

💭 A quick note: virtCCA’s measured-boot and remote-attestation features landed in stages as the product was commercialized, scattering the code across components and fragmenting the documentation. This article consolidates the framework at the architectural level, so readers don’t have to dig through scattered older sources.

Introduction

Huawei virtCCA is a confidential-computing solution built on the TrustZone and Secure EL2 features of the Kunpeng processor. It brings the Arm CCA architectural concepts to existing hardware, giving applications and data a hardware-rooted, verifiable Trusted Execution Environment (TEE) that isolates them from unauthorized access or tampering at runtime.

virtCCA bridges toward native CCA hardware while migrating business applications without modification. Until CCA hardware is widespread, it gives enterprises a practical option with high performance, strong security, and forward compatibility. See virtCCA: Virtualized Arm Confidential Compute Architecture with TrustZone and the Confidential Computing TEE Suite Technical White Paper for details.

As Figure 1 shows, hardware isolation draws the trust boundary, and Measured Boot and Attestation make the state inside it cryptographically verifiable:

• Measured Boot: following “measure before execute”, virtCCA hashes the TCB state during platform and CVM (Confidential VM) boot, then stores the results in tamper-resistant registers.

• Attestation: a hardware-protected Attestation Key signs the measurements to produce an Attestation Report, proving the CVM and its platform are genuine and untampered.

Together they build a chain of trust from the hardware Root of Trust (RoT) up to the CVM. A Relying Party can then verify remotely that a workload runs inside a CVM on a genuine virtCCA platform and meets the expected security baseline.

💡 TCB (Trusted Computing Base): the set of hardware, firmware, and software components that must be trusted to keep the system secure. It includes hardware (CPU, RoT), firmware (TF-A, TMM), and critical Guest OS code (UEFI, the GRUB bootloader, the OS kernel). If any TCB component is exploited or modified, the system’s confidentiality and integrity no longer hold.

Measured Boot

The virtCCA architecture consists of the CVM and the underlying virtCCA platform (hardware plus firmware) that hosts it — mirroring the Realm / CCA Platform split in the Arm CCA specification (see Arm CCA Security Model 1.0). Given this separation, end-to-end Measured Boot comes in two interlocking phases — Platform Measurement and CVM Measurement — shown in Figure 2. Only when the Platform Measurement verifies does the CVM Measurement it carries mean anything.

Platform Measurement

Platform Measurement follows a chained trust-transfer model. During hardware initialization BSBC acts as the Core Root of Trust for Measurement (CRTM); the HSM running on InSE acts as the Root of Trust for Storage (RTS) and the Root of Trust for Reporting (RTR), storing results in InSE’s protected internal SRAM (Figure 2). By boot order, virtCCA follows the Arm CCA firmware-boot specification (Trusted Subsystems → Application PE → Monitor → RMM). In practice, the functional-component boundaries differ from Arm CCA because of constraints in the existing Kunpeng hardware, as the table below shows.

💡 RoTs are components that must be trusted because their misbehavior cannot be detected: (1) the Root of Trust for Measurement (RTM) measures software and forwards the results to the RTS; (2) the Root of Trust for Storage is access-controlled, tamper-resistant storage; (3) the Root of Trust for Reporting reports the RTS’s contents — measurement values — as an attestation report; (4) the CRTM is the first code executed after reset and anchors the chain of trust.

CVM Measurement

virtCCA supports two CVM boot methods (Figure 3): Direct Kernel Boot and Virtual Firmware Boot.

• Direct Kernel Boot: the Hypervisor (QEMU/KVM) loads the OS kernel and the initial RAM filesystem (initramfs) directly, bypassing the virtual firmware and bootloader.
• Virtual Firmware Boot: virtual firmware (UEFI) initializes hardware and loads a bootloader such as GRUB, which then loads the kernel and initramfs. We call this UEFI Boot in the rest of the article.

Direct Kernel Boot starts fast with a small resource footprint, a good fit for lightweight container environments (e.g., Kata Container). UEFI Boot works with existing OS images, handles complex boot configurations such as multi-kernel and multi-boot management, and preserves the cloud-management experience of a regular VM — a good fit for general-purpose VMs (e.g., IaaS cloud instances).

Both paths follow the same security primitive: Host-provided assets are untrusted. Any input from the Hypervisor (code, data, configuration) must be measured by the TMM — or by an RTM it delegates to — before it is used. The measurements are then extended into specific TMM-protected registers. Per the Realm Management Monitor specification (A7.1 Realm measurements), these are the RIM (Realm Initial Measurement) and the REM (Realm Event Measurement). The TMM computes the RIM directly, capturing the initial register and memory state; subsequent RTMs compute the REM — for example, UEFI measuring the GRUB image it loads.

Direct Kernel Boot

When a CVM boots via Direct Kernel Boot, virtCCA’s measurement logic follows the Arm CCA RMM specification. Since virtCCA’s TMM is closed-source, this section uses RMM terminology. The table below summarizes the three phases; for details, see B4.3.9.4 RMI_REALM_CREATE initialization of RIM, B4.3.12.4 RMI_REC_CREATE extension of RIM, and B4.3.1.4 RMI_DATA_CREATE extension of RIM in the Realm Management Monitor specification.

Virtual Firmware Boot

For UEFI-firmware-booted CVMs, the Arm CCA measurement specification did not yet exist at the time, so virtCCA developed its own solution ahead of the standard. Unlike the fixed flow of Direct Kernel Boot, the UEFI boot chain uses diverse boot media and dynamic configuration, making its path highly non-deterministic. Drawing on the trusted-boot mechanisms of TCG and TDX, virtCCA built a deterministic, measurable, and auditable boot pipeline.

🍵 For technical details on Intel TDX’s Trusted Boot, see this companion article: Intel TDX: Measured Boot and Attestation in Grub Boot.

As Figure 4 shows, although the UEFI boot combinations are many, the factors that affect the system’s security state are relatively fixed. virtCCA measures every security-sensitive element — boot variables, image files, and boot order — uniformly, and builds a reproducible, verifiable Event Log that covers any UEFI boot combination.

Concretely, in the pre-kernel-load environment (spanning the UEFI and bootloader stages), all critical state is measured through EFI_CC_MEASUREMENT_PROTOCOL and extended into REM. The protocol also records each measurement into the CCEL (Confidential Computing Event Log) within the ACPI tables. A CVM can then verify REM by replaying the log, auditing the entire chain of trust end-to-end.

Figure 5 shows virtCCA’s measurement components in UEFI firmware. EFI_CC_MEASUREMENT_PROTOCOL wraps the low-level measurement logic for confidential-computing environments. Per the UEFI Specification 2.10, it provides hash computation and event-log APIs, and defines the semantic mapping from traditional TPM PCRs to virtCCA REMs (table below). The CcaTcg2Dxe.c driver handles measurement during the DXE phase; the DxeTpm2MeasureBootLib library handles integrity measurement of PE images and the GPT partition table. Source: src-openeuler/edk2, patches 97–106 (“Support measurement when UEFI Boot CVM”). For the flow, see the Measured Boot Flow section of Intel TDX: Measured Boot and Attestation in Grub Boot.

Attestation

Under the Delegated Attestation model, several parties share the work of producing the attestation report. As Figure 2 shows, the virtCCA Token wraps two Sub-Tokens: the CVM Token and the Platform Token. The HSM in InSE generates the Platform Token; the TMM caches it in secure memory for performance. The TMM then generates the CVM Token and combines both into the virtCCA Token.

Authenticity

Each generating entity signs its Sub-Token with a dedicated key, making the chain of trust traceable. The keys derive in a chain: the entity that produced the predecessor Sub-Token derives the next key. To block Sub-Token substitution attacks, Sub-Tokens are cryptographically bound through a “hash anchoring” mechanism — the predecessor Sub-Token’s Challenge embeds the hash of the successor Sub-Token’s public key.

In virtCCA’s key hierarchy: CPAK signs the Platform Token, derived by the HSM from a root key and platform parameters; its public-key certificate is issued by the Huawei Root CA and Sub CA, giving a hardware-rooted identity proof. RAK signs the CVM Token, derived during TMM initialization by the HSM from the root key, the virtCCA platform measurement, and other parameters.

🍵 Since the virtCCA TMM is a closed-source component, the details of how it interacts with the HSM to obtain the RAK and the Platform Token can be found in the Delegated Attestation Service Integration Guide.

Attestation Flow

The virtCCA SDK is a user-space toolkit for enabling and integrating remote attestation (Figure 6). Its companion Attestation Demo shows the end-to-end flow: the Server runs inside the CVM and exposes the device certificate (CPAK) and the attestation report (virtCCA Token) through the TSI interface. The Client acts as a Local Verifier, parsing the certificate and report, validating the certificate chain, and evaluating the security policy.

🍵 For other features — for example Full Disk Encryption, see attestation/full-disk-encryption; for virtCCA’s adaptation of RATS-TLS, see attestation/rats-tls.

The diagram below shows the Attestation Demo flow. For real-world deployment and usage, see the feature guide Enabling Remote Attestation.

Summary

Measured boot and remote attestation make for a great “visible trust” story, and everyone loves telling it. For engineers, though, the work really does span the stack — grinding from chip, firmware, and OS up through applications and infrastructure, with one eye on the standards and ecosystem the whole time. After all that, it can be hard to point at exactly where the value lands, and honestly the tech itself isn’t all that flashy, 🥲😅.

Anyway, virtCCA has done some of this work, with plenty still to improve. Keep at it, CCA folks.