# [Secure Realms during boot using Arm Confidential Compute Architecture BootSync](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-bootsync/)

## In this learning path

- [Introduction](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-bootsync/)
- [Understand Arm CCA BootSync and the Boot Injection protocol](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync/)
- [Configure UEFI Secure Boot and disk encryption in Arm CCA Realms](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-bootsync/flow/)
- [Next Steps](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-bootsync/_next-steps/)

## About this Learning Path
| Skill level:            | Advanced         |
|-------------------------|------------------|
| Reading time:           | 1 hr             |
| Last updated:           | 07 Aug 2026      |

### Authors:
- Anton Antonov
- Pareena Verma, Arm  
  [GitHub](https://github.com/pareenaverma)  
  [LinkedIn](https://linkedin.com/in/pareena-verma-7853607)

### Arm IP:
- [Neoverse](https://support.arm.com/?tab=compute-ip&Product%20Type=Infrastructure%20Processors)
- [Cortex-A](https://support.arm.com/?tab=compute-ip&Product%20Type=Application%20Processors)

### Tags:
- [Performance and Architecture](https://learn.arm.com/tag/performance-and-architecture)
- [Linux](https://learn.arm.com/tag/linux)
- [FVP](https://learn.arm.com/tag/fvp)
- [RME](https://learn.arm.com/tag/rme)
- [CCA](https://learn.arm.com/tag/cca)
- [Docker](https://learn.arm.com/tag/docker)
- [EDK2](https://learn.arm.com/tag/edk2)
- [Cryptsetup](https://learn.arm.com/tag/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:
- A cloud-based instance or an AArch64 or x86_64 computer running Linux. For more information about using cloud-based instances, see the [Arm cloud service providers](https://learn.arm.com/learning-paths/servers-and-cloud-computing/csp/) Learning Path.
- Completion of the [Run an application in a Realm using the Arm Confidential Compute Architecture (CCA)](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-container/) Learning Path.

### Summary
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
<details>
<summary>Do I need networking inside the Realm to deliver boot data?</summary>
No. BootSync operates before the guest operating system has networking and uses the Boot Injection protocol to provide early boot data.
</details>

<details>
<summary>How do I know BootSync requested variable data?</summary>
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.
</details>

<details>
<summary>What result should I expect when Secure Boot is configured but the kernel is unsigned?</summary>
The unsigned kernel is rejected. This confirms that UEFI Secure Boot is enforcing signature verification.
</details>

<details>
<summary>After I sign the kernel, how do I verify that Secure Boot is enabled?</summary>
The signed kernel boots successfully and the Secure Boot UEFI variable reports `1`. Check that value to confirm the state.
</details>

<details>
<summary>How do I confirm the encrypted root file system unlocks correctly?</summary>
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 `/`.
</details>