virtCCA: Measured Boot and Attestation Demystified

Created in January 21, 2026

2026   ·   security  ·  EN / 中文

Contents

💭 A quick note: virtCCA’s measured-boot and remote-attestation features were added gradually as the product matured. The implementation now spans several components, while the documentation is scattered across sources written at different times. This article brings those pieces together into one architectural view.

Introduction

Huawei virtCCA is a confidential-computing system built on the TrustZone and Secure EL2 features of Kunpeng processors. It implements the main ideas of Arm CCA on existing hardware: applications run in a hardware-isolated Trusted Execution Environment (TEE) whose state can be verified.

virtCCA also provides a migration path toward native CCA hardware without requiring changes to existing applications. See virtCCA: Virtualized Arm Confidential Compute Architecture with TrustZone and the Confidential Computing TEE Suite Technical White Paper for details.

Hardware isolation draws the trust boundary. Measured Boot and Attestation make the state within that boundary verifiable, as shown in Figure 1:

  • Measured Boot: following the rule “measure before execute,” virtCCA hashes the state of its Trusted Computing Base (TCB) while the platform and Confidential VM (CVM) boot. It records the resulting measurements in protected registers.

  • Attestation: a hardware-protected Attestation Key signs those measurements and places them in an Attestation Report. A verifier uses the report to establish the identity and measured state of the CVM and its platform.

The result is a chain of trust from the hardware Root of Trust (RoT) to the CVM. A Relying Party can check remotely that a workload is running in a CVM on a genuine virtCCA platform and that its measurements match an accepted security baseline.

Figure 1. Measured Boot and Attestation

💡 The Trusted Computing Base (TCB) is the hardware, firmware, and software that the system depends on for security. In virtCCA it includes hardware such as the CPU and RoT, firmware such as TF-A and the TMM, and critical guest code such as UEFI, GRUB, and the OS kernel. A vulnerability or unauthorized change in any of these components can break the system’s confidentiality or integrity.

Measured Boot

The virtCCA architecture separates a CVM from the underlying hardware and firmware that host it. This corresponds to the distinction between a Realm and the CCA Platform in the Arm CCA specification (see Arm CCA Security Model 1.0). Measured Boot therefore has two linked parts, shown in Figure 2: Platform Measurement and CVM Measurement. A CVM measurement is useful only when the platform reporting it can also be trusted.

Figure 2. Platform Measurement and CVM Measurement

Platform Measurement

Platform Measurement passes trust from one boot stage to the next. During hardware initialization, the BSBC serves as the Core Root of Trust for Measurement (CRTM). The HSM running on the InSE provides the Root of Trust for Storage (RTS) and Root of Trust for Reporting (RTR), with measurements held in the InSE’s protected internal SRAM (Figure 2). The boot order follows the Arm CCA firmware model: Trusted Subsystems → Application PE → Monitor → RMM. The component boundaries differ from native Arm CCA because virtCCA works within the architecture of existing Kunpeng hardware.

Measured Components Description
BSBC (BootROM Secure Boot Code) Secure boot code embedded in the on-chip ROM
ESBC (External Secure Boot Code) Secure boot code stored in off-chip non-volatile memory
InSE (Integrated Secure Element) An on-chip secure subsystem with physical-security protection
HSM (Hardware Security Module) High-security firmware running on InSE; provides key management, secure storage, and Platform-token generation
IMU (Intelligence Management Unit) Intelligent management unit responsible for hardware management, monitoring, and secure boot
IPU TBA
ATF (Arm Trusted Firmware) Low-level secure firmware running at the highest exception level (EL3)
TMM (TrustZone Management Monitor) A lightweight secure-monitoring component responsible for the CVM lifecycle, memory isolation, and interface dispatch
UEFI (Unified Extensible Firmware Interface) Platform boot firmware that initializes hardware, performs security checks, and boots the system
IMF AP TBA

💡 Roots of Trust (RoTs) are components whose incorrect behavior cannot be detected by another component in the same trust model. The Root of Trust for Measurement (RTM) measures software and sends the values to the RTS. The Root of Trust for Storage keeps those values in access-controlled, tamper-resistant storage. The Root of Trust for Reporting turns the stored measurements into an attestation report. The CRTM is the first code to run after reset and starts this chain.

CVM Measurement

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

  • Direct Kernel Boot: the hypervisor (QEMU/KVM) loads the OS kernel and initial RAM filesystem (initramfs) directly, without virtual firmware or a bootloader.
  • Virtual Firmware Boot: virtual firmware (UEFI) initializes the virtual hardware and loads a bootloader such as GRUB; the bootloader then loads the kernel and initramfs. The rest of this article calls this path UEFI Boot.

Direct Kernel Boot starts quickly and uses fewer resources, which suits lightweight container environments such as Kata Containers. UEFI Boot works with existing OS images and more complex configurations, including multiple kernels and boot entries. It also behaves more like a conventional VM from the cloud management layer, making it a better fit for general-purpose IaaS instances.

Figure 3. Direct Kernel Boot and Firmware Boot

Both paths start from the same security rule: assets supplied by the host are untrusted. Before the CVM uses host-supplied code, data, or configuration, the TMM—or an RTM to which it delegates the work—must measure it. Those measurements are extended into registers protected by the TMM. Section A7.1 of the Realm Management Monitor specification defines two kinds of register: the Realm Initial Measurement (RIM) and Realm Event Measurements (REMs). The TMM calculates the RIM from the CVM’s initial register and memory state. Later boot stages extend the REMs; for example, UEFI measures the GRUB image before loading it.

Direct Kernel Boot

For Direct Kernel Boot, virtCCA follows the measurement model in the Arm CCA RMM specification. The TMM is closed source, so the description below uses the corresponding RMM terminology. The three operations are summarized in the table. Their definitions appear in sections 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) of the Realm Management Monitor specification.

Phase Description
Create a Realm
A CCA Realm corresponds to a virtCCA CVM.
Command: RMI_REALM_CREATE
Function: measurement_realm_params_measure()
Components:
  • flags: lpa2 (LPA2 enabled), sve (SVE enabled), pmu (PMU enabled)
  • s2sz: requested IPA width
  • sve_vl: requested SVE vector length
  • num_bps: number of breakpoints
  • num_wps: number of watchpoints
  • pmu_num_ctrs: requested number of PMU counters
  • hash_algo: algorithm used to measure the initial state of the Realm
Create a REC
A REC is the execution context associated with a Realm vCPU.
Command: RMI_REC_CREATE
Function: measurement_rec_params_measure()
Components:
  • gprs (general-purpose registers): the host supplies the initial values of registers 0–7; the remaining registers are zeroed
  • pc (program counter): the primary REC starts at the Realm's LOADER_START_ADDR; the PCs of other RECs are zeroed
  • flags: includes runnable, which indicates whether a REC may execute; the primary REC is runnable
Create a Data Granule
Copies content such as the kernel or initramfs from a Non-secure Granule supplied by the caller.
Command: RMI_DATA_CREATE
Function: measurement_data_granule_measure()
Components:
  • ipa: IPA at which the DATA Granule is mapped in the Realm
  • flags: indicates whether to measure the DATA Granule's contents
  • content: the hash of the DATA Granule's contents, or zero when the flags mark those contents as unmeasured

Virtual Firmware Boot

When virtCCA added support for UEFI Boot, Arm CCA had not yet defined a measurement specification for this path. virtCCA therefore designed its own scheme, drawing on the trusted-boot mechanisms used by TCG and TDX. UEFI Boot is harder to measure than Direct Kernel Boot because its boot media and configuration can vary. The scheme has to preserve evidence of those choices without assuming a single fixed sequence.

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

Figure 4. Measurement in UEFI Boot

The possible UEFI boot paths are numerous, but the inputs that determine their security state fall into a smaller set. virtCCA measures boot variables, image files, boot order, and other security-sensitive inputs, then records the measurements in an Event Log. This gives the verifier a reproducible account of the path that was actually taken rather than requiring every valid path to be enumerated in advance.

Before the kernel is loaded, UEFI and the bootloader measure critical state through EFI_CC_MEASUREMENT_PROTOCOL and extend the results into the REMs. The protocol records the same events in the Confidential Computing Event Log (CCEL), exposed through an ACPI table. A verifier can replay that log, reconstruct the REM values, and compare them with the values in the attestation token. Matching values show that the log corresponds to the measured boot sequence; policy evaluation still determines whether that sequence is acceptable.

Figure 5. Measured Boot Components in EDK2

Figure 5 shows the components that implement measurement in virtCCA’s UEFI firmware. EFI_CC_MEASUREMENT_PROTOCOL provides the hashing and event-log interface for a confidential-computing guest. Following the UEFI Specification 2.10, the implementation maps the conventional uses of TPM PCRs to virtCCA REMs, as summarized below. The CcaTcg2Dxe.c driver handles DXE-phase measurements, while DxeTpm2MeasureBootLib measures PE images and the GPT partition table. The implementation is carried by patches 97–106 (“Support measurement when UEFI Boot CVM”) in src-openeuler/edk2. The Measured Boot Flow section of Intel TDX: Measured Boot and Attestation in Grub Boot describes the analogous flow in more detail.

TPM PCR TDX virtCCA/CCA Typical Usage of Measurement Registers
0 MRTD RIM Virtual firmware code (corresponds to PCR[0])
1, 7 RTMR[0] REM0 Firmware configuration (corresponds to PCR[1,7])
2~6 RTMR[1] REM1 Components loaded by firmware, such as the OS loader (corresponds to PCR[4,5])
8~15 RTMR[2] REM2 OS components such as the kernel, initrd, and applications (corresponds to PCR[8–15]); exact usage depends on the OS
16+ RTMR[3] REM3 Reserved for special-purpose use

Attestation

virtCCA uses delegated attestation: the platform and the CVM each produce part of the evidence instead of relying on one component to report on the entire stack. As Figure 2 shows, a virtCCA Token contains two sub-tokens, the Platform Token and the CVM Token. The HSM in the InSE generates the Platform Token, which the TMM caches in secure memory. The TMM generates the CVM Token and packages the two together.

Authenticity

Each component signs its own sub-token with a dedicated key. The keys form a derivation chain: the component responsible for the preceding sub-token derives the key used for the next one. The sub-tokens must also be bound to each other; otherwise, an attacker could replace one with evidence from another system. virtCCA prevents this by placing the hash of the successor’s public key in the predecessor sub-token’s Challenge field.

Two keys matter here. The CCA Platform Attestation Key (CPAK) signs the Platform Token. The HSM derives it from a root key and platform parameters, and Huawei’s Root CA and subordinate CA issue the corresponding certificate. The Realm Attestation Key (RAK) signs the CVM Token. During TMM initialization, the HSM derives the RAK from the root key, the virtCCA platform measurement, and other parameters.

🍵 The virtCCA TMM is closed source, so its exact interaction with the HSM is not publicly visible. The Delegated Attestation Service Integration Guide describes the corresponding integration pattern for obtaining a RAK and Platform Token.

Attestation Flow

The virtCCA SDK provides the user-space interfaces needed to integrate remote attestation (Figure 6). Its Attestation Demo shows the complete exchange. A server inside the CVM obtains the device certificate and virtCCA Token through the TSI interface and returns them to a client. The client is the Local Verifier: it parses the evidence, validates the certificate chain and token signatures, compares the measurements with reference values, and applies its appraisal policy.

Figure 6. Component Details in virtCCA SDK

🍵 The SDK repository also contains examples for Full Disk Encryption and virtCCA’s integration with RATS-TLS.

The sequence below follows the Attestation Demo. For deployment instructions, see Enabling Remote Attestation.

Summary

Measured boot and remote attestation are often presented as a neat story about making trust visible. The engineering is less neat. It stretches from the chip through firmware and the OS to applications and infrastructure, while standards and the surrounding ecosystem continue to evolve. After all that work, the visible result is simply evidence that a verifier can compare with reference values and policy. It may not look exciting, but producing trustworthy evidence across the whole stack takes a great deal of work. 🥲😅

virtCCA has implemented part of that path, though there is still plenty to improve. Keep going, CCA folks.