Secure Realms during boot using Arm Confidential Compute Architecture (CCA) BootSync
Introduction
Understand Arm CCA BootSync and the Boot Injection protocol
Configure UEFI Secure Boot and disk encryption in Arm CCA Realms
Next Steps

  Log an issue

  Fork and edit

  Discuss on Discord

About this Learning Path

Skill level:  Advanced
Reading time:  1 hr
Last updated:  17 Jul 2026
Skill level:
  Advanced
Reading time:
  1 hr
Last updated:
  17 Jul 2026
Authors:Anton Antonov
Pareena Verma, Arm
Arm IP:Neoverse Cortex-A
Tags: Performance and Architecture Linux FVP RME CCA Docker EDK2 Cryptsetup
Authors:
  • Anton Antonov
  • Pareena Verma, Arm
Arm IP:
Neoverse Cortex-A
Tags:
Performance and Architecture Linux FVP RME CCA Docker EDK2 Cryptsetup

Who is this for?

This Learning Path is for developers who want to understand how Arm CCA BootSync supports early Realm boot workflows such as UEFI Secure Boot and encrypted disk boot.

What will you learn?

Upon completion of this Learning Path, you will be able to:

  • Understand why BootSync is needed before the Realm guest operating system has networking.
  • Understand how the Boot Injection Protocol uses key exchange, attestation, and Boot Information Blocks to support the BootSync workflow.
  • Use BootSync to inject UEFI variables and secret data into an Arm CCA Realm.
  • Launch Arm CCA Realms with UEFI Secure Boot and an encrypted root file system on an Armv9-A AEM Base Fixed Virtual Platform (FVP) with Realm Management Extension (RME) support.

Prerequisites

Before starting, you will need the following:

Summary

AI-assisted

This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
You’ll use Arm CCA BootSync on an RME-enabled Armv9-A AEM Base FVP to deliver UEFI variables and secrets to a Realm during early boot, then validate Secure Boot and encrypted disk startup. First, you’ll launch a Realm without injected data to observe firmware attestation. Next, you’ll provide variable data for BootSync to complete and verify that Secure Boot rejects the unsigned kernel. After signing the kernel, you’ll verify that Secure Boot is active. Finally, you’ll encrypt the Realm root file system, inject the file system decryption secret through BootSync, and confirm that the disk unlocks during boot.

Frequently asked questions

AI-assisted

These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
Do I need networking inside the Realm to deliver boot data?
No. BootSync operates before the guest operating system has networking and uses the Boot Injection protocol to provide early boot data.
How do I know BootSync requested variable data?
In the User Context service log, you’ll see BIB Variable Data Requested and the expected <RPV>_VAR.dat file name. If the file is missing, BootSync reports BootSyncNotDone, and the Realm boots without Secure Boot enabled.
What result should I expect when Secure Boot is configured but the kernel is unsigned?
The unsigned kernel is rejected. This confirms that UEFI Secure Boot is enforcing signature verification.
After I sign the kernel, how do I verify that Secure Boot is enabled?
The signed kernel boots successfully and the Secure Boot UEFI variable reports 1. Check that value to confirm the state.
How do I confirm the encrypted root file system unlocks correctly?
After BootSync supplies the correct passphrase, the boot log reports LUKS partition unlocked, switching root. Run df -h and verify that /dev/mapper/cryptroot is mounted at /.
Next