From 9736e1307002e5bfd792438fc2957e4165bb45b2 Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Thu, 16 Jul 2026 17:00:00 -0500 Subject: [PATCH 1/9] one editorial pass of CCA BootSync --- .../cca-bootsync/_index.md | 10 +++------- .../cca-bootsync/cca-bootsync.md | 20 ++++++++++++------- .../cca-bootsync/flow.md | 20 +++++++++---------- 3 files changed, 26 insertions(+), 24 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md index 306d47b171..c69828841d 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md @@ -1,18 +1,14 @@ --- -title: Arm CCA BootSync +title: Launch Realms using Arm Confidential Compute Architecture (CCA) BootSync description: Learn how Arm CCA BootSync transfers boot-time configuration and secret data to a Realm while launching CCA Realms on an FVP with RME support. -draft: true -cascade: - draft: true - minutes_to_complete: 60 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. learning_objectives: - - Explain why BootSync is needed before the Realm guest operating system has networking. - - Describe how the Boot Injection Protocol uses key exchange, attestation, and Boot Information Blocks to support the BootSync workflow. + - Understand why BootSync is needed before the Realm guest operating system has networking. + - Learn 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 FVP with RME support. diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md index bd61e6f726..7eed1308b0 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md @@ -1,6 +1,6 @@ --- # User change -title: "Overview of Arm CCA BootSync and the Boot Injection Protocol" +title: Understand Arm CCA BootSync and the Boot Injection Protocol weight: 2 # 1 is first, 2 is second, etc. @@ -8,18 +8,20 @@ weight: 2 # 1 is first, 2 is second, etc. layout: "learningpathall" --- -## Design overview +## What Arm CCA Bootsync is -Arm CCA BootSync is a boot-time synchronization mechanism for Arm CCA Realms. It lets Realm guest firmware obtain configuration and secret data before the guest operating system is running. This matters because early firmware does not have a network stack, but workflows such as UEFI Secure Boot and encrypted disk boot still need trusted inputs during that early boot window. +Arm Confidential Compute Architecture (CCA) BootSync is a boot-time synchronization mechanism for Arm CCA Realms. The mechanism lets Realm guest firmware obtain configuration and secret data before the guest operating system is running. This matters because early firmware does not have a network stack, but workflows such as UEFI Secure Boot and encrypted disk boot still need trusted inputs during that early boot window. -The reference implementation uses the *Boot Injection Protocol*, named the BIB protocol in the Boot Injection appendix of the Realm Host Interface (RHI) specification. In this Learning Path, you use BootSync to provide two kinds of data to a Realm: +The reference implementation uses the *Boot Injection Protocol*, named the BIB protocol in the Boot Injection appendix of the Realm Host Interface (RHI) specification. + +You'll use BootSync to provide two kinds of data to a Realm: - Variable data, such as UEFI variables used to configure Secure Boot. - Secret data, such as a disk unlock passphrase or other boot-time secret. The data is not just copied into the Realm. BootSync first establishes a protected exchange between the Realm guest firmware and a *User Context* service controlled by the Realm initiator. The User Context service runs outside the Realm, but it represents the party that decides whether the Realm should receive the requested boot information. -## Component roles +## Components of BootSync flow The BootSync flow spans both the Normal World host and the Realm World guest: @@ -30,7 +32,7 @@ The BootSync flow spans both the Normal World host and the Realm World guest: The practical result is that the Realm firmware can get boot-time data without needing direct networking. The host can carry the request, but the release decision belongs to the User Context after the Realm has provided attestation evidence. -## Boot Injection Protocol stages +## Stages of Boot Injection Protocol The Boot Injection Protocol has three logical stages: @@ -49,4 +51,8 @@ The exercises intentionally show both failure and success cases: For more detail, see the [ArmCcaBootSync README](https://gitlab.arm.com/linux-arm/edk2-cca/-/blob/cca/4441_measured_boot_v1/ArmVirtPkg/ArmCcaBootSync/Readme.md), the [Realm Management Monitor specification](https://developer.arm.com/documentation/den0137/latest/), and the [Realm Host Interface specification](https://developer.arm.com/documentation/den0148/latest/). -In the next section, you will launch Realms and see how Arm CCA BootSync can inject UEFI variables and secret data during early boot. +## What you've learned and what's next + +You've learned what Arm CCA BootSync is and what the stages of the Boot Injection Protocol are. + +Next, you'll launch Realms and see how Arm CCA BootSync can inject UEFI variables and secret data during early boot. diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md index 34f9849017..5ceca74fc0 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md @@ -1,26 +1,26 @@ --- # User change -title: "Arm CCA BootSync" +title: Launch an Arm CCA Realm with UEFI Secure Boot on Arm FVP weight: 3 # 1 is first, 2 is second, etc. # Do not modify these elements layout: "learningpathall" --- -## Overview +## What you'll build -In this section, you will run the **User Context** service in a Docker container, launch a **CCA Realm** on **Arm FVP** in a separate Docker container, and use Arm CCA BootSync to provide Realm UEFI variables and secret data during early boot. +You'll run the User Context service in a Docker container, launch a CCA Realm on Arm FVP in a separate Docker container, and use Arm CCA BootSync to provide Realm UEFI variables and secret data during early boot. -The flow uses two terminals: +You'll uses two terminals: -- Terminal 1 runs the User Context service. This service represents the Realm initiator and decides whether to release BootSync data. -- Terminal 2 runs the Arm CCA FVP and launches Realm VMs using `lkvm-bootsync`. +- In the first terminal, you'll run the User Context service. This service represents the Realm initiator and decides whether to release BootSync data. +- In the second terminal, you'll run the Arm CCA FVP and launches Realm VMs using `lkvm-bootsync`. -You will first observe a BootSync failure when required data is missing, then fix the flow and validate UEFI Secure Boot. Finally, you will use BootSync secret data to unlock an encrypted root file system. +You'll first observe a BootSync failure when required data is missing, then fix the flow and validate UEFI Secure Boot. Finally, you will use BootSync secret data to unlock an encrypted root file system. ## Install dependencies -Start by installing Docker. On Ubuntu 24.04 LTS, set up Docker's APT repository so you can pull and run the pre-built Learning Path containers: +Start by installing Docker. On Ubuntu 24.04 LTS, set up Docker's APT repository so you can pull and run the pre-built containers: ```bash # Add Docker's official GPG key: @@ -38,7 +38,7 @@ echo \ sudo apt-get update ``` -Install Git and Docker packages. `git` is useful for inspecting linked source files, and the Docker packages provide the runtime used by both the User Context and FVP containers: +Install `git` for inspecting linked source files, and Docker packages for the runtime used by both the User Context and FVP containers: ```bash sudo apt-get install -y git docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin @@ -51,7 +51,7 @@ sudo usermod -aG docker $USER newgrp docker ``` -## Start User Context service +## Start the User Context service First, pull the Docker image with the pre-built User Context service, and then run the container. From e7b78e6e3f63e8002b05021eab513786ff5d5107 Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Fri, 17 Jul 2026 10:49:48 -0500 Subject: [PATCH 2/9] completing the first editorial pass of BootSync + adding a generic takeaway --- .../cca-bootsync/_index.md | 2 +- .../cca-bootsync/cca-bootsync.md | 16 +- .../cca-bootsync/flow.md | 153 ++++++++++-------- 3 files changed, 94 insertions(+), 77 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md index c69828841d..1fea587d3c 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md @@ -1,6 +1,6 @@ --- title: Launch Realms using Arm Confidential Compute Architecture (CCA) BootSync -description: Learn how Arm CCA BootSync transfers boot-time configuration and secret data to a Realm while launching CCA Realms on an FVP with RME support. +description: Learn how Arm CCA BootSync transfers boot-time configuration and secret data to a Realm while launching a Realm on an FVP with RME support. minutes_to_complete: 60 diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md index 7eed1308b0..60dc771323 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md @@ -10,7 +10,7 @@ layout: "learningpathall" ## What Arm CCA Bootsync is -Arm Confidential Compute Architecture (CCA) BootSync is a boot-time synchronization mechanism for Arm CCA Realms. The mechanism lets Realm guest firmware obtain configuration and secret data before the guest operating system is running. This matters because early firmware does not have a network stack, but workflows such as UEFI Secure Boot and encrypted disk boot still need trusted inputs during that early boot window. +Arm Confidential Compute Architecture (CCA) BootSync is a boot-time synchronization mechanism for Arm CCA Realms. The mechanism lets Realm guest firmware obtain configuration and secret data before the guest operating system is running. This matters because early firmware doesn't have a network stack, but workflows such as UEFI Secure Boot and encrypted disk boot still need trusted inputs during that early boot window. The reference implementation uses the *Boot Injection Protocol*, named the BIB protocol in the Boot Injection appendix of the Realm Host Interface (RHI) specification. @@ -27,7 +27,7 @@ The BootSync flow spans both the Normal World host and the Realm World guest: - The *Realm guest firmware* starts BootSync early in boot and requests boot information. - The *Realm Management Monitor* (RMM) exposes Realm services and creates attestation reports for the Realm. -- The *Virtual Machine Manager* (VMM), `lkvm-bootsync` in this Learning Path, forwards Realm Host Interface calls between the Realm and host user space. +- The *Virtual Machine Manager* (VMM), in this case `lkvm-bootsync`, forwards Realm Host Interface calls between the Realm and host user space. - The *User Context* service receives BootSync requests, verifies attestation evidence, and returns encrypted boot information when the Realm is allowed to receive it. The practical result is that the Realm firmware can get boot-time data without needing direct networking. The host can carry the request, but the release decision belongs to the User Context after the Realm has provided attestation evidence. @@ -42,14 +42,14 @@ The Boot Injection Protocol has three logical stages: ## What you will validate -The exercises intentionally show both failure and success cases: +You'll validate both failure and success cases: -- First, you launch a Realm without injection of any boot data. This demonstrates that the firmware can run successful attestation and ask for BootSync data. -- Next, you add the variable data file. BootSync completes, UEFI Secure Boot is enabled, and the unsigned kernel is rejected. -- Then, you sign the Realm kernel. The Realm boots with UEFI Secure Boot enabled, and the Secure Boot UEFI variable reports `1`. -- Finally, you encrypt the Realm root file system and use BootSync secret data to provide the unlock passphrase during boot. +- First, you'll launch a Realm without injection of any boot data to see that the firmware can run successful attestation and ask for BootSync data. +- Next, you'll add the variable data file. BootSync completes, UEFI Secure Boot is enabled, and the unsigned kernel is rejected. +- Then, you'll sign the Realm kernel. The Realm boots with UEFI Secure Boot enabled, and the Secure Boot UEFI variable reports `1`. +- Finally, you'll encrypt the Realm root file system and use BootSync secret data to provide the unlock passphrase during boot. -For more detail, see the [ArmCcaBootSync README](https://gitlab.arm.com/linux-arm/edk2-cca/-/blob/cca/4441_measured_boot_v1/ArmVirtPkg/ArmCcaBootSync/Readme.md), the [Realm Management Monitor specification](https://developer.arm.com/documentation/den0137/latest/), and the [Realm Host Interface specification](https://developer.arm.com/documentation/den0148/latest/). +For more information, see the [ArmCcaBootSync README](https://gitlab.arm.com/linux-arm/edk2-cca/-/blob/cca/4441_measured_boot_v1/ArmVirtPkg/ArmCcaBootSync/Readme.md), the [Realm Management Monitor specification](https://developer.arm.com/documentation/den0137/latest/), and the [Realm Host Interface specification](https://developer.arm.com/documentation/den0148/latest/). ## What you've learned and what's next diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md index 5ceca74fc0..7f38cdb6a5 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md @@ -1,13 +1,13 @@ --- # User change -title: Launch an Arm CCA Realm with UEFI Secure Boot on Arm FVP +title: Launch Arm CCA Realms with UEFI Secure Boot on Arm FVP weight: 3 # 1 is first, 2 is second, etc. # Do not modify these elements layout: "learningpathall" --- -## What you'll build +## What you will build You'll run the User Context service in a Docker container, launch a CCA Realm on Arm FVP in a separate Docker container, and use Arm CCA BootSync to provide Realm UEFI variables and secret data during early boot. @@ -44,18 +44,17 @@ Install `git` for inspecting linked source files, and Docker packages for the ru sudo apt-get install -y git docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin ``` -Add your user name to the Docker group so you can run Docker without `sudo`. The group change applies to new shells; `newgrp docker` updates the current terminal: +Add your user name to the Docker group so you can run Docker without `sudo`: ```bash sudo usermod -aG docker $USER newgrp docker ``` +The group change applies to new shells; `newgrp docker` updates the current terminal. ## Start the User Context service -First, pull the Docker image with the pre-built User Context service, and then run the container. - -The `cca-trustee` Docker network is important. It lets the FVP container resolve the User Context service by container name, `user-context`, when `lkvm-bootsync` later uses `--service-ip user-context`. +First, pull the Docker image with the pre-built User Context service. Then, run the container: ```bash docker pull armswdev/cca-learning-path:cca-key-broker-v4 @@ -63,15 +62,17 @@ docker network create cca-trustee docker run --rm -it --network cca-trustee --name user-context armswdev/cca-learning-path:cca-key-broker-v4 ``` -Now within your running Docker container, start the User Context service using the `run-user-context-service.sh` script. -The User Context service in this Learning Path is part of the [EDK2](https://gitlab.arm.com/linux-arm/edk2-cca/-/tree/cca/4441_measured_boot_v1/ArmVirtPkg/ArmCcaBootSync/UserContext) project. -It has been created specifically for POC purposes, so is intentionally small and simple to understand, and is not designed for production use. +The `cca-trustee` Docker network is important. It lets the FVP container resolve the User Context service by container name, `user-context`, when `lkvm-bootsync` later uses `--service-ip user-context`. + +Now, within your running Docker container, start the User Context service using the `run-user-context-service.sh` script. +The User Context service is part of the [EDK2](https://gitlab.arm.com/linux-arm/edk2-cca/-/tree/cca/4441_measured_boot_v1/ArmVirtPkg/ArmCcaBootSync/UserContext) project. +Created specifically as a proof of concept, it's intentionally small and not designed for production use. When the script starts for the first time, it generates Secure Boot signing certificates and creates a Provisioning Data file. The Provisioning Data is a binary file generated by [GenPd.py](https://gitlab.arm.com/linux-arm/edk2-cca/-/blob/cca/4441_measured_boot_v1/ArmVirtPkg/ArmCcaBootSync/Scripts/GenPd.py) script. The file contains EFI variable definitions required for enabling UEFI Secure Boot. -You will be asked for a passphrase for the Secure Boot signing certificates. Remember it because you will use it again when signing the Realm kernel. +You'll be asked for a passphrase for the Secure Boot signing certificates. Remember it because you'll use it again when signing the Realm kernel. ```bash ./run-user-context-service.sh @@ -79,9 +80,9 @@ You will be asked for a passphrase for the Secure Boot signing certificates. Rem ## Launch a CCA Realm without Secure Boot enabled -With the User Context service running in one terminal, open up a new terminal in which you will run CCA realms. +With the User Context service running in one terminal, open up a new terminal in which you'll run CCA realms. -Pull the Docker image with the pre-built FVP and CCA reference software stack, and then run the container connected to the same Docker network: +Pull the Docker image with the pre-built FVP and CCA reference software stack. Then, run the container connected to the same Docker network: ```bash docker pull armswdev/cca-learning-path:cca-simulation-v4 @@ -106,13 +107,7 @@ host login: root (host) # ``` -Change directory to `/cca` and use `lkvm-bootsync` to launch a guest Linux in a Realm. - -The BootSync-specific parameters are: - -- `--service-ip user-context` points the VMM to the User Context container on the Docker network. -- `--service-port 1080` uses the default User Context service port. -- `--realm-pv ARMCCA01` sets the Realm Personalization Value (RPV). The User Context uses this value as a file-name prefix when looking for BootSync data, such as `ARMCCA01_VAR.dat` and `ARMCCA01_SEC.dat`. +Change directory to `/cca` and use `lkvm-bootsync` to launch a guest Linux in a Realm: ```bash cd /cca @@ -124,10 +119,16 @@ cd /cca --service-port 1080 \ --realm-pv ARMCCA01 ``` +The BootSync-specific parameters are: + +- `--service-ip user-context` points the VMM to the User Context container on the Docker network. +- `--service-port 1080` uses the default User Context service port. +- `--realm-pv ARMCCA01` sets the Realm Personalization Value (RPV). The User Context uses this value as a file-name prefix when looking for BootSync data, such as `ARMCCA01_VAR.dat` and `ARMCCA01_SEC.dat`. + +After running the command, you'll see the Realm boot. -You should see the realm boot. +The output is similar to: -In the realm boot output, UEFI Secure Boot is not mentioned in EFI messages. This is expected because you have not yet provided the UEFI variable data that enables Secure Boot: ```output Shell> bootaa64.efi root=/dev/vda2 acpi=force ip=on EFI stub: Booting Linux Kernel... @@ -135,7 +136,9 @@ EFI stub: Generating empty DTB EFI stub: Exiting boot services... ``` -After the realm boots, log in, using the root again as the username: +UEFI Secure Boot isn't mentioned in the EFI messages. This is expected because you've not yet provided the UEFI variable data that enables Secure Boot. + +After the Realm boots, log in using the root again as the username: ```output Welcome to the CCA realm @@ -151,13 +154,13 @@ efivar -p -d -n {global}-SecureBoot 0 ``` -Stop the realm: +Stop the Realm: ```bash poweroff ``` -On the terminal with the User Context service, you can see that the Realm firmware requested a Variable Data file, but the file is missing. This is the intentional failure in this step: BootSync completed enough of the protocol to request boot information, but the User Context had no `ARMCCA01_VAR.dat` file to release. +On the terminal with the User Context service, you can see that the Realm firmware requested a Variable Data file, but the file is missing: ```output INFO: BIB Variable Data Requested @@ -168,22 +171,24 @@ Info: Session State: ConnectionEstablished Info: Attestation State: AttSuccess Info: BootSync State: BootSyncNotDone ``` +This is an intentional failure: BootSync completed enough of the protocol to request boot information, but the User Context had no `ARMCCA01_VAR.dat` file to release. -In the next step, you will add the missing Boot Information Block data and repeat the launch. +Next, you'll add the missing Boot Information Block data and repeat the launch. ## Launch a CCA Realm with Secure Boot enabled -On the terminal with the User Context service stop the service by pressing `Ctrl-C`. +On the terminal with the User Context service, stop the service by pressing `Ctrl-C`. -The RPV and file names used here are details of this Learning Path's reference implementation. One User Context service can support multiple Realms by using the RPV as a file-name prefix. A Realm launched with `--realm-pv ARMCCA01` requests files that start with `ARMCCA01`. If the matching files are missing, BootSync can establish a session and complete attestation, but the User Context cannot provide the requested boot information. +The RPV and file names used here are details of this Learning Path's reference implementation. One User Context service can support multiple Realms by using the RPV as a file-name prefix. A Realm launched with `--realm-pv ARMCCA01` requests files that start with `ARMCCA01`. If the matching files are missing, BootSync can establish a session and complete attestation, but the User Context can't provide the requested boot information. -Copy the generated Provisioning Data file to a Realm variable data file with the name `_VAR.dat`. Because you launched the Realm with `--realm-pv ARMCCA01`, the User Context service looks for `ARMCCA01_VAR.dat`: +Copy the generated Provisioning Data file to a Realm variable data file with the name `_VAR.dat`: ```bash cp SecureBoot/SecBootCert/pd.bin SecureBoot/ARMCCA01_VAR.dat ``` +Because you launched the Realm with `--realm-pv ARMCCA01`, the User Context service looks for `ARMCCA01_VAR.dat`. -Create a Secret Data file with data that will be shared with a Realm using the same RPV. This first secret is just a visible test string so you can prove that the data reaches the Realm: +Create a Secret Data file with a test string that'll be shared with a Realm using the same RPV: ```bash echo "My Realm secret data" > SecureBoot/ARMCCA01_SEC.dat @@ -195,7 +200,7 @@ Relaunch the User Context service: ./run-user-context-service.sh ``` -On the terminal with FVP, relaunch the Realm with the same RPV. Keeping the same `--realm-pv ARMCCA01` is what links the Realm request to the files you just created: +On the terminal with FVP, relaunch the Realm with the same RPV: ```bash cd /cca @@ -208,7 +213,9 @@ cd /cca --realm-pv ARMCCA01 ``` -On the terminal with the User Context service, you can see that attestation succeeded and BootSync completed. This means the User Context released the Boot Information Blocks to the Realm firmware: +Keeping the same `--realm-pv ARMCCA01` is what links the Realm request to the files you created. + +On the terminal with the User Context service, you can see that attestation succeeded and BootSync completed: ```output Info: Received FIN. Disconnecting. @@ -216,6 +223,7 @@ Info: Session State: UnConnected Info: Attestation State: AttSuccess Info: BootSync State: BootSyncCompete ``` +This means the User Context released the Boot Information Blocks to the Realm firmware. The Realm now fails to boot the Linux kernel: @@ -224,17 +232,19 @@ Shell> bootaa64.efi root=/dev/vda2 acpi=force ip=on Script Error Status: Access Denied (line number 1) ``` -Stop the realm by entering "reset" command to EFI shell prompt: +This failure is expected. The same kernel booted before Secure Boot was enabled, but now the firmware enforces the Secure Boot variables injected by BootSync. The kernel image isn't signed yet, so firmware rejects it. + +Stop the realm by running `reset` in the EFI shell prompt: ```bash reset ``` -This failure is expected. The same kernel booted before Secure Boot was enabled, but now the firmware enforces the Secure Boot variables injected by BootSync. The kernel image is not signed yet, so firmware rejects it. You will fix that in the next step. +Next, you'll launch a Realm with a signed kernel image. ## Launch a CCA Realm with Secure Boot enabled and a signed Linux kernel -On the terminal with FVP, use the `sign_guest_kernel.sh` script to sign the Realm Linux kernel with the Secure Boot certificate generated earlier by the User Context setup script. You will be asked for the passphrase you used for the Secure Boot signing certificates. +On the terminal with FVP, use the `sign_guest_kernel.sh` script to sign the Realm Linux kernel with the Secure Boot certificate generated earlier by the User Context setup script. When prompted, enter the passphrase you used for the Secure Boot signing certificates: ```bash { output_lines="2-3" } sign_guest_kernel.sh @@ -256,9 +266,10 @@ cd /cca --realm-pv ARMCCA01 ``` -You should see the Realm boot. +You'll see the Realm boot. + +The output is similar to: -In the Realm boot output, the EFI messages show that UEFI Secure Boot is enabled: ```output Shell> bootaa64.efi root=/dev/vda2 acpi=force ip=on EFI stub: Booting Linux Kernel... @@ -266,6 +277,7 @@ EFI stub: UEFI Secure Boot is enabled. EFI stub: Generating empty DTB EFI stub: Exiting boot services... ``` +The EFI messages show that UEFI Secure Boot is enabled. After the Realm boots, log in using `root` as the username: @@ -290,8 +302,8 @@ efivar -d -p -n {global}-SetupMode 0 ``` -Via [securityfs](https://www.kernel.org/doc/Documentation/ABI/testing/securityfs-secrets-coco) you can -access the secret data shared with the Realm. In this demo, the data is exposed under the `GRUB_EFI_DISKPASSWD_GUID` entry: +Using [securityfs](https://www.kernel.org/doc/Documentation/ABI/testing/securityfs-secrets-coco), you can +access the secret data shared with the Realm from under the `GRUB_EFI_DISKPASSWD_GUID` entry: ```bash { output_lines="3" } mount -t securityfs none /sys/kernel/security @@ -299,51 +311,50 @@ cat /sys/kernel/security/secrets/coco/736869e5-84f0-4973-92ec-06879ce3da0b My Realm secret data ``` -Stop the realm: +Stop the Realm: ```bash poweroff ``` -You have successfully started a realm with UEFI Secure Boot configured and enabled via Arm CCA BootSync. +You've successfully started a Realm with UEFI Secure Boot configured and enabled via Arm CCA BootSync. ## Launch a CCA Realm with an encrypted root file system -The secure data shared with a Realm via Arm CCA BootSync can also be used to provide access to encrypted file systems. In this part of the Learning Path, you encrypt the root file system, observe a failed unlock when the wrong secret is available, and then update the BootSync secret so the Realm can unlock the disk during boot. +You can use the secure data shared with a Realm using Arm CCA BootSync to provide access to encrypted file systems. You'll now encrypt the root file system, observe a failed unlock when the wrong secret is available, and update the BootSync secret so the Realm can unlock the disk during boot. -{{% notice Access to encrypted partitions %}} +{{% notice Note %}} There are different ways to provide a Realm with access to encrypted partitions using Arm CCA BootSync. For example: - Use an updated version of [Grub](https://gitlab.arm.com/linux-arm/grub-cca/-/tree/cca/4441_measured_boot_v1) as a boot loader. -This version of Grub uses the secret data to open an encrypted partition and load kernel and initrd images from it. -This is an example grub config file: -```output -echo 'Mounting encrypted disk...' -cryptomount -s efisecret (hd0,gpt2) + This version of Grub uses the secret data to open an encrypted partition and load kernel and initrd images from it. + This is an example grub config file: + ```output + echo 'Mounting encrypted disk...' + cryptomount -s efisecret (hd0,gpt2) -echo 'Loading Kernel...' -linux (crypto0)/bootaa64.efi + echo 'Loading Kernel...' + linux (crypto0)/bootaa64.efi -echo 'Loading InitRD...' -initrd (crypto0)/initrd.gz + echo 'Loading InitRD...' + initrd (crypto0)/initrd.gz -echo 'Booting Linux...' -boot -``` -With the current Grub implementation of Arm CCA BootSync support, the booted operating system has access to the initramfs only. + echo 'Booting Linux...' + boot + ``` + With the current Grub implementation of Arm CCA BootSync support, the booted operating system has access to the initramfs only. - Use an init script in an initrd image to unlock and mount the encrypted partition. You will use this approach in the next steps. {{% /notice %}} +On the terminal with the running FVP, use the `encrypt_rootfs.sh` script to encrypt the root partition in the Realm disk image and add an `initrd` image to the kernel parameters. -On the terminal with the running FVP, use the `encrypt_rootfs.sh` script to encrypt the root partition in the Realm disk image and add an initrd image to the kernel parameters. - -You will be asked for a passphrase to encrypt the root partition. Use a memorable test passphrase for this demo and keep it available, because you will later write the same value into `ARMCCA01_SEC.dat` for BootSync to release. +You'll be asked for a passphrase to encrypt the root partition. Use a memorable test passphrase and keep it available, because you'll later write the same value into `ARMCCA01_SEC.dat` for BootSync to release. You can use maximum of 512 characters of upper/lowercase, numbers and symbols. -You can ignore the warning message because this demo uses small partitions. +Ignore the warning message because you're using small partitions. ```bash { output_lines="2-11" } encrypt_rootfs.sh @@ -372,7 +383,7 @@ cd /cca --realm-pv ARMCCA01 ``` -In the realm boot log you can see that the Init script failed to unlock the encrypted partition: +In the realm boot log, you can see that the Init script failed to unlock the encrypted partition: ```output [ 32.761651] Run /init as init process @@ -387,8 +398,9 @@ can't run '/etc/init.d/rcS': No such file or directory Please press Enter to activate this console. ``` -Press Enter to get into the Realm shell. -In the shell, check that only the initramfs is mounted and that you cannot mount `/dev/vda2` directly: +Press `Enter` to get into the Realm shell. + +In the shell, check that only `initramfs` is mounted and that you can't mount `/dev/vda2` directly: ```bash { output_lines="2-3" } df -h @@ -401,17 +413,17 @@ mount -t auto /dev/vda2 /cryptroot mount: mounting /dev/vda2 on /cryptroot failed: Invalid argument ``` -Stop the realm: +Stop the Realm: ```bash poweroff ``` -The init script failed to unlock the encrypted partition because the Secret Data file does not contain the encryption passphrase yet. Now update the BootSync secret. +The init script failed to unlock the encrypted partition because the Secret Data file doesn't contain the encryption passphrase yet. Now, update the BootSync secret. -On the terminal with the User Context service stop the service by pressing `Ctrl-C`. +On the terminal with the User Context service, stop the service by pressing `Ctrl-C`. -Save the encryption passphrase into the Secret Data file. Use `echo -n` so the file contains only the passphrase and no trailing newline character. +Save the encryption passphrase into the Secret Data file. Use `echo -n` so the file contains only the passphrase and no trailing newline character: ```bash ROOTFS_PASSPHRASE='replace-with-the-passphrase-you-used-for-encrypt_rootfs' @@ -438,6 +450,7 @@ cd /cca ``` In the Realm boot log, you can see that the init script successfully unlocked and mounted the encrypted partition: + ```output [ 233.501627] Run /init as init process Detecting LUKS containers in vda1-2 @@ -468,7 +481,7 @@ tmpfs 194.8M 32.0K 194.8M 0% /run cgroup 194.8M 0 194.8M 0% /sys/fs/cgroup ``` -Stop the realm: +Stop the Realm: ```bash poweroff @@ -480,4 +493,8 @@ Stop the FVP: poweroff ``` -You have successfully tested launching realms with Arm CCA BootSync. +## What you've accomplished + +You've now succesfully tested launching Realms with Arm CCA BootSync. + +You can extend the workflows covered in this Learning Path to your own workloads. From 704843c3276ba244cbc362abba9d568b4d6b2c8f Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Fri, 17 Jul 2026 11:19:25 -0500 Subject: [PATCH 3/9] style updates --- .../cca-bootsync/_index.md | 4 +-- .../cca-bootsync/cca-bootsync.md | 16 ++++----- .../cca-bootsync/flow.md | 33 +++++++++++-------- 3 files changed, 30 insertions(+), 23 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md index 1fea587d3c..bf702c4d4a 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md @@ -1,6 +1,6 @@ --- title: Launch Realms using Arm Confidential Compute Architecture (CCA) BootSync -description: Learn how Arm CCA BootSync transfers boot-time configuration and secret data to a Realm while launching a Realm on an FVP with RME support. +description: Learn how Arm CCA BootSync transfers boot-time configuration and secret data when you launch a Realm on an FVP with RME support. minutes_to_complete: 60 @@ -10,7 +10,7 @@ learning_objectives: - Understand why BootSync is needed before the Realm guest operating system has networking. - Learn 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 FVP with RME support. + - 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: - An AArch64 or x86_64 computer running Linux or macOS. Cloud-based instances can also be used; see the [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md index 60dc771323..fdcaf5bdb9 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md @@ -8,20 +8,20 @@ weight: 2 # 1 is first, 2 is second, etc. layout: "learningpathall" --- -## What Arm CCA Bootsync is +## What Arm CCA BootSync is Arm Confidential Compute Architecture (CCA) BootSync is a boot-time synchronization mechanism for Arm CCA Realms. The mechanism lets Realm guest firmware obtain configuration and secret data before the guest operating system is running. This matters because early firmware doesn't have a network stack, but workflows such as UEFI Secure Boot and encrypted disk boot still need trusted inputs during that early boot window. -The reference implementation uses the *Boot Injection Protocol*, named the BIB protocol in the Boot Injection appendix of the Realm Host Interface (RHI) specification. +The reference implementation uses the *Boot Injection protocol*. The Boot Injection appendix of the Realm Host Interface (RHI) specification refers to the protocol as the BIB protocol. You'll use BootSync to provide two kinds of data to a Realm: - Variable data, such as UEFI variables used to configure Secure Boot. - Secret data, such as a disk unlock passphrase or other boot-time secret. -The data is not just copied into the Realm. BootSync first establishes a protected exchange between the Realm guest firmware and a *User Context* service controlled by the Realm initiator. The User Context service runs outside the Realm, but it represents the party that decides whether the Realm should receive the requested boot information. +Before data is copied into the Realm, BootSync establishes a protected exchange between the Realm guest firmware and a *User Context* service controlled by the Realm initiator. The User Context service runs outside the Realm, but it decides whether the Realm should receive the requested boot information. -## Components of BootSync flow +## Components of the BootSync flow The BootSync flow spans both the Normal World host and the Realm World guest: @@ -32,9 +32,9 @@ The BootSync flow spans both the Normal World host and the Realm World guest: The practical result is that the Realm firmware can get boot-time data without needing direct networking. The host can carry the request, but the release decision belongs to the User Context after the Realm has provided attestation evidence. -## Stages of Boot Injection Protocol +## Stages of the Boot Injection protocol -The Boot Injection Protocol has three logical stages: +The Boot Injection protocol has three logical stages: 1. Key exchange establishes a secure session between the Realm guest firmware and the User Context service. The reference implementation uses ECDH over the P-384 curve, derives keys with HKDF-SHA512, and encrypts protocol data with AES-GCM. 2. Attestation lets the Realm guest firmware request an attestation report from the RMM. The binding key from the secure session is used as challenge data, so the User Context can bind the attestation evidence to this BootSync exchange. @@ -44,7 +44,7 @@ The Boot Injection Protocol has three logical stages: You'll validate both failure and success cases: -- First, you'll launch a Realm without injection of any boot data to see that the firmware can run successful attestation and ask for BootSync data. +- First, you'll launch a Realm without injecting any boot data to see that the firmware can run successful attestation and ask for BootSync data. - Next, you'll add the variable data file. BootSync completes, UEFI Secure Boot is enabled, and the unsigned kernel is rejected. - Then, you'll sign the Realm kernel. The Realm boots with UEFI Secure Boot enabled, and the Secure Boot UEFI variable reports `1`. - Finally, you'll encrypt the Realm root file system and use BootSync secret data to provide the unlock passphrase during boot. @@ -53,6 +53,6 @@ For more information, see the [ArmCcaBootSync README](https://gitlab.arm.com/lin ## What you've learned and what's next -You've learned what Arm CCA BootSync is and what the stages of the Boot Injection Protocol are. +You’ve learned how Arm CCA BootSync uses key exchange, attestation, and Boot Information Blocks to provide trusted data during Realm boot. Next, you'll launch Realms and see how Arm CCA BootSync can inject UEFI variables and secret data during early boot. diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md index 7f38cdb6a5..d669d314bc 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md @@ -1,6 +1,6 @@ --- # User change -title: Launch Arm CCA Realms with UEFI Secure Boot on Arm FVP +title: Secure an Arm CCA Realm with UEFI Secure Boot and disk encryption weight: 3 # 1 is first, 2 is second, etc. @@ -9,12 +9,12 @@ layout: "learningpathall" --- ## What you will build -You'll run the User Context service in a Docker container, launch a CCA Realm on Arm FVP in a separate Docker container, and use Arm CCA BootSync to provide Realm UEFI variables and secret data during early boot. +You'll run the User Context service in a Docker container and launch CCA Realms on an Arm Fixed Virtual Platform (FVP) in a separate Docker container. You'll use Arm CCA BootSync to provide Realm UEFI variables and secret data during early boot. -You'll uses two terminals: +You'll use two terminals: - In the first terminal, you'll run the User Context service. This service represents the Realm initiator and decides whether to release BootSync data. -- In the second terminal, you'll run the Arm CCA FVP and launches Realm VMs using `lkvm-bootsync`. +- In the second terminal, you'll run the Arm CCA FVP and launch Realm VMs using `lkvm-bootsync`. You'll first observe a BootSync failure when required data is missing, then fix the flow and validate UEFI Secure Boot. Finally, you will use BootSync secret data to unlock an encrypted root file system. @@ -266,8 +266,6 @@ cd /cca --realm-pv ARMCCA01 ``` -You'll see the Realm boot. - The output is similar to: ```output @@ -321,15 +319,18 @@ You've successfully started a Realm with UEFI Secure Boot configured and enabled ## Launch a CCA Realm with an encrypted root file system -You can use the secure data shared with a Realm using Arm CCA BootSync to provide access to encrypted file systems. You'll now encrypt the root file system, observe a failed unlock when the wrong secret is available, and update the BootSync secret so the Realm can unlock the disk during boot. +You can use the secret data shared with a Realm using Arm CCA BootSync to provide access to encrypted file systems. You'll now encrypt the root file system, observe a failed unlock when the wrong secret is available, and update the BootSync secret so the Realm can unlock the disk during boot. + +### Encrypt the root file system {{% notice Note %}} There are different ways to provide a Realm with access to encrypted partitions using Arm CCA BootSync. For example: - Use an updated version of [Grub](https://gitlab.arm.com/linux-arm/grub-cca/-/tree/cca/4441_measured_boot_v1) as a boot loader. - This version of Grub uses the secret data to open an encrypted partition and load kernel and initrd images from it. - This is an example grub config file: + This version of Grub uses the secret data to open an encrypted partition and load kernel and `initrd` images from it. + + The following is an example Grub config file: ```output echo 'Mounting encrypted disk...' cryptomount -s efisecret (hd0,gpt2) @@ -353,7 +354,7 @@ On the terminal with the running FVP, use the `encrypt_rootfs.sh` script to encr You'll be asked for a passphrase to encrypt the root partition. Use a memorable test passphrase and keep it available, because you'll later write the same value into `ARMCCA01_SEC.dat` for BootSync to release. -You can use maximum of 512 characters of upper/lowercase, numbers and symbols. +You can use a maximum of 512 characters of uppercase or lowercase letters, numbers, and symbols. Ignore the warning message because you're using small partitions. ```bash { output_lines="2-11" } @@ -370,6 +371,8 @@ WARNING: keyslots area (1015808 bytes) is very small, available LUKS2 keyslot co Enable Initrd image ``` +### Validate the failed unlock + Relaunch the Realm. At this point, `ARMCCA01_SEC.dat` still contains the test string from the previous Secure Boot step, not the disk encryption passphrase: ```bash @@ -383,7 +386,7 @@ cd /cca --realm-pv ARMCCA01 ``` -In the realm boot log, you can see that the Init script failed to unlock the encrypted partition: +In the Realm boot log, you can see that the init script failed to unlock the encrypted partition: ```output [ 32.761651] Run /init as init process @@ -419,7 +422,11 @@ Stop the Realm: poweroff ``` -The init script failed to unlock the encrypted partition because the Secret Data file doesn't contain the encryption passphrase yet. Now, update the BootSync secret. +The init script failed to unlock the encrypted partition because the Secret Data file doesn't contain the encryption passphrase yet. + +### Update the BootSync secret and validate a successful unlock + +Now, update the BootSync secret. On the terminal with the User Context service, stop the service by pressing `Ctrl-C`. @@ -495,6 +502,6 @@ poweroff ## What you've accomplished -You've now succesfully tested launching Realms with Arm CCA BootSync. +You’ve now used Arm CCA BootSync to enable UEFI Secure Boot and unlock an encrypted root file system for a Realm. You can extend the workflows covered in this Learning Path to your own workloads. From 72a7f606aee3bfed81304c3d483a53458314131c Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Fri, 17 Jul 2026 12:28:35 -0500 Subject: [PATCH 4/9] updating titles and removing macOS from prereqs, plus other structure/SEO updates --- .../cca-bootsync/_index.md | 9 ++++---- .../cca-bootsync/cca-bootsync.md | 4 +--- .../cca-bootsync/flow.md | 22 +++++++++---------- 3 files changed, 16 insertions(+), 19 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md index bf702c4d4a..1f48b7fcf4 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md @@ -1,6 +1,6 @@ --- -title: Launch Realms using Arm Confidential Compute Architecture (CCA) BootSync -description: Learn how Arm CCA BootSync transfers boot-time configuration and secret data when you launch a Realm on an FVP with RME support. +title: Secure Realms during boot using Arm Confidential Compute Architecture (CCA) BootSync +description: Use Arm CCA BootSync to transfer boot-time configuration and secret data when you launch a Realm on an FVP with RME support. minutes_to_complete: 60 @@ -8,12 +8,12 @@ who_is_this_for: This Learning Path is for developers who want to understand how learning_objectives: - Understand why BootSync is needed before the Realm guest operating system has networking. - - Learn how the Boot Injection Protocol uses key exchange, attestation, and Boot Information Blocks to support the BootSync workflow. + - 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: - - An AArch64 or x86_64 computer running Linux or macOS. Cloud-based instances can also be used; see the [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/) + - 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](/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)](/learning-paths/servers-and-cloud-computing/cca-container/) Learning Path author: @@ -32,7 +32,6 @@ armips: - Cortex-A operatingsystems: - Linux - - macOS tools_software_languages: - FVP - RME diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md index fdcaf5bdb9..be6a7ef324 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md @@ -12,7 +12,7 @@ layout: "learningpathall" Arm Confidential Compute Architecture (CCA) BootSync is a boot-time synchronization mechanism for Arm CCA Realms. The mechanism lets Realm guest firmware obtain configuration and secret data before the guest operating system is running. This matters because early firmware doesn't have a network stack, but workflows such as UEFI Secure Boot and encrypted disk boot still need trusted inputs during that early boot window. -The reference implementation uses the *Boot Injection protocol*. The Boot Injection appendix of the Realm Host Interface (RHI) specification refers to the protocol as the BIB protocol. +The reference implementation uses the *Boot Injection protocol*. The Boot Injection appendix of the [Realm Host Interface (RHI) specification](https://developer.arm.com/documentation/den0148/latest/) refers to the protocol as the BIB protocol. You'll use BootSync to provide two kinds of data to a Realm: @@ -49,8 +49,6 @@ You'll validate both failure and success cases: - Then, you'll sign the Realm kernel. The Realm boots with UEFI Secure Boot enabled, and the Secure Boot UEFI variable reports `1`. - Finally, you'll encrypt the Realm root file system and use BootSync secret data to provide the unlock passphrase during boot. -For more information, see the [ArmCcaBootSync README](https://gitlab.arm.com/linux-arm/edk2-cca/-/blob/cca/4441_measured_boot_v1/ArmVirtPkg/ArmCcaBootSync/Readme.md), the [Realm Management Monitor specification](https://developer.arm.com/documentation/den0137/latest/), and the [Realm Host Interface specification](https://developer.arm.com/documentation/den0148/latest/). - ## What you've learned and what's next You’ve learned how Arm CCA BootSync uses key exchange, attestation, and Boot Information Blocks to provide trusted data during Realm boot. diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md index d669d314bc..93ba8b85bb 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md @@ -1,13 +1,13 @@ --- # User change -title: Secure an Arm CCA Realm with UEFI Secure Boot and disk encryption +title: Configure UEFI Secure Boot and disk encryption in Arm CCA Realms weight: 3 # 1 is first, 2 is second, etc. # Do not modify these elements layout: "learningpathall" --- -## What you will build +## What you will configure and validate You'll run the User Context service in a Docker container and launch CCA Realms on an Arm Fixed Virtual Platform (FVP) in a separate Docker container. You'll use Arm CCA BootSync to provide Realm UEFI variables and secret data during early boot. @@ -20,7 +20,7 @@ You'll first observe a BootSync failure when required data is missing, then fix ## Install dependencies -Start by installing Docker. On Ubuntu 24.04 LTS, set up Docker's APT repository so you can pull and run the pre-built containers: +Set up Docker's `apt` repository so you can pull and run the pre-built containers: ```bash # Add Docker's official GPG key: @@ -38,7 +38,7 @@ echo \ sudo apt-get update ``` -Install `git` for inspecting linked source files, and Docker packages for the runtime used by both the User Context and FVP containers: +Install Docker packages for the runtime used by both the User Context and FVP containers, and optionally install `git` for inspecting linked source files: ```bash sudo apt-get install -y git docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin @@ -78,7 +78,7 @@ You'll be asked for a passphrase for the Secure Boot signing certificates. Remem ./run-user-context-service.sh ``` -## Launch a CCA Realm without Secure Boot enabled +## Verify BootSync without Secure Boot enabled With the User Context service running in one terminal, open up a new terminal in which you'll run CCA realms. @@ -175,7 +175,7 @@ This is an intentional failure: BootSync completed enough of the protocol to req Next, you'll add the missing Boot Information Block data and repeat the launch. -## Launch a CCA Realm with Secure Boot enabled +## Enable Secure Boot and validate unsigned kernel rejection On the terminal with the User Context service, stop the service by pressing `Ctrl-C`. @@ -242,7 +242,7 @@ reset Next, you'll launch a Realm with a signed kernel image. -## Launch a CCA Realm with Secure Boot enabled and a signed Linux kernel +## Sign the kernel and verify Secure Boot On the terminal with FVP, use the `sign_guest_kernel.sh` script to sign the Realm Linux kernel with the Secure Boot certificate generated earlier by the User Context setup script. When prompted, enter the passphrase you used for the Secure Boot signing certificates: @@ -315,13 +315,13 @@ Stop the Realm: poweroff ``` -You've successfully started a Realm with UEFI Secure Boot configured and enabled via Arm CCA BootSync. +You've successfully started a Realm with UEFI Secure Boot configured and enabled using Arm CCA BootSync. -## Launch a CCA Realm with an encrypted root file system +## Encrypt the root file system and update the secret for disk unlock You can use the secret data shared with a Realm using Arm CCA BootSync to provide access to encrypted file systems. You'll now encrypt the root file system, observe a failed unlock when the wrong secret is available, and update the BootSync secret so the Realm can unlock the disk during boot. -### Encrypt the root file system +### Encrypt the root partition {{% notice Note %}} @@ -504,4 +504,4 @@ poweroff You’ve now used Arm CCA BootSync to enable UEFI Secure Boot and unlock an encrypted root file system for a Realm. -You can extend the workflows covered in this Learning Path to your own workloads. +You can extend the workflows covered in this Learning Path to your own Realm workloads. From 33e72a2091fc04268783cd018e504737dfb34de2 Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Fri, 17 Jul 2026 12:34:23 -0500 Subject: [PATCH 5/9] adding and updating metadata descriptions --- .../servers-and-cloud-computing/cca-bootsync/_index.md | 2 +- .../servers-and-cloud-computing/cca-bootsync/cca-bootsync.md | 1 + .../servers-and-cloud-computing/cca-bootsync/flow.md | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md index 1f48b7fcf4..64218714f2 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md @@ -1,6 +1,6 @@ --- title: Secure Realms during boot using Arm Confidential Compute Architecture (CCA) BootSync -description: Use Arm CCA BootSync to transfer boot-time configuration and secret data when you launch a Realm on an FVP with RME support. +description: Use Arm CCA BootSync on an RME-enabled FVP to inject UEFI variables and secrets to unlock the disk during boot, then verify Secure Boot and encrypted root file system startup. minutes_to_complete: 60 diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md index be6a7ef324..fbe0b71d2f 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md @@ -1,6 +1,7 @@ --- # User change title: Understand Arm CCA BootSync and the Boot Injection Protocol +description: Understand how Arm CCA BootSync uses key exchange, attestation, and Boot Information Blocks to deliver trusted configuration and secret data during Realm boot. weight: 2 # 1 is first, 2 is second, etc. diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md index 93ba8b85bb..bb6458dce1 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md @@ -1,6 +1,7 @@ --- # User change title: Configure UEFI Secure Boot and disk encryption in Arm CCA Realms +description: Configure Arm CCA BootSync on an FVP, verify UEFI Secure Boot with a signed kernel, and unlock an encrypted Realm root file system. weight: 3 # 1 is first, 2 is second, etc. From 1d2c0c0bca73627b26efef1e1c119d2a889652e1 Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Fri, 17 Jul 2026 12:34:52 -0500 Subject: [PATCH 6/9] nit --- .../servers-and-cloud-computing/cca-bootsync/flow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md index bb6458dce1..2bd2f4f683 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md @@ -15,7 +15,7 @@ You'll run the User Context service in a Docker container and launch CCA Realms You'll use two terminals: - In the first terminal, you'll run the User Context service. This service represents the Realm initiator and decides whether to release BootSync data. -- In the second terminal, you'll run the Arm CCA FVP and launch Realm VMs using `lkvm-bootsync`. +- In the second terminal, you'll run the Arm CCA FVP and launch Realm virtual machines using `lkvm-bootsync`. You'll first observe a BootSync failure when required data is missing, then fix the flow and validate UEFI Secure Boot. Finally, you will use BootSync secret data to unlock an encrypted root file system. From 16f26a4e14f819bd84e656ae875d823b1a211726 Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Fri, 17 Jul 2026 12:35:03 -0500 Subject: [PATCH 7/9] nit --- .../servers-and-cloud-computing/cca-bootsync/flow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md index 2bd2f4f683..c1cad84fa4 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md @@ -17,7 +17,7 @@ You'll use two terminals: - In the first terminal, you'll run the User Context service. This service represents the Realm initiator and decides whether to release BootSync data. - In the second terminal, you'll run the Arm CCA FVP and launch Realm virtual machines using `lkvm-bootsync`. -You'll first observe a BootSync failure when required data is missing, then fix the flow and validate UEFI Secure Boot. Finally, you will use BootSync secret data to unlock an encrypted root file system. +You'll first observe a BootSync failure when required data is missing, then fix the flow and validate UEFI Secure Boot. Finally, you'll use BootSync secret data to unlock an encrypted root file system. ## Install dependencies From d7269492df7bc287309b505c465c4e7970c0ea00 Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Fri, 17 Jul 2026 13:27:18 -0500 Subject: [PATCH 8/9] another pass --- .../cca-bootsync/cca-bootsync.md | 11 +------ .../cca-bootsync/flow.md | 30 ++++++++++--------- 2 files changed, 17 insertions(+), 24 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md index fbe0b71d2f..631dc8e7bd 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md @@ -1,6 +1,6 @@ --- # User change -title: Understand Arm CCA BootSync and the Boot Injection Protocol +title: Understand Arm CCA BootSync and the Boot Injection protocol description: Understand how Arm CCA BootSync uses key exchange, attestation, and Boot Information Blocks to deliver trusted configuration and secret data during Realm boot. weight: 2 # 1 is first, 2 is second, etc. @@ -41,15 +41,6 @@ The Boot Injection protocol has three logical stages: 2. Attestation lets the Realm guest firmware request an attestation report from the RMM. The binding key from the secure session is used as challenge data, so the User Context can bind the attestation evidence to this BootSync exchange. 3. Boot Information Blocks carry the requested boot data after attestation succeeds. -## What you will validate - -You'll validate both failure and success cases: - -- First, you'll launch a Realm without injecting any boot data to see that the firmware can run successful attestation and ask for BootSync data. -- Next, you'll add the variable data file. BootSync completes, UEFI Secure Boot is enabled, and the unsigned kernel is rejected. -- Then, you'll sign the Realm kernel. The Realm boots with UEFI Secure Boot enabled, and the Secure Boot UEFI variable reports `1`. -- Finally, you'll encrypt the Realm root file system and use BootSync secret data to provide the unlock passphrase during boot. - ## What you've learned and what's next You’ve learned how Arm CCA BootSync uses key exchange, attestation, and Boot Information Blocks to provide trusted data during Realm boot. diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md index c1cad84fa4..a7baf79902 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md @@ -10,14 +10,16 @@ layout: "learningpathall" --- ## What you will configure and validate -You'll run the User Context service in a Docker container and launch CCA Realms on an Arm Fixed Virtual Platform (FVP) in a separate Docker container. You'll use Arm CCA BootSync to provide Realm UEFI variables and secret data during early boot. +You'll configure and validate both failure and success cases: -You'll use two terminals: +- First, you'll launch a Realm without injecting any boot data to see that the firmware can run successful attestation and ask for BootSync data. +- Next, you'll add the variable data file. BootSync completes, UEFI Secure Boot is enabled, and the unsigned kernel is rejected. +- Then, you'll sign the Realm kernel and validate Secure Boot. The Realm boots with UEFI Secure Boot enabled, and the Secure Boot UEFI variable reports `1`. +- Finally, you'll encrypt the Realm root file system and use BootSync secret data to provide UEFI variables and the unlock passphrase during early boot. You'll unlock the encrypted file system. -- In the first terminal, you'll run the User Context service. This service represents the Realm initiator and decides whether to release BootSync data. -- In the second terminal, you'll run the Arm CCA FVP and launch Realm virtual machines using `lkvm-bootsync`. +You'll run the User Context service in a Docker container and launch CCA Realms on an Arm Fixed Virtual Platform (FVP) in a separate Docker container. -You'll first observe a BootSync failure when required data is missing, then fix the flow and validate UEFI Secure Boot. Finally, you'll use BootSync secret data to unlock an encrypted root file system. +You'll use two terminals. In the first terminal, you'll run the User Context service. This service represents the Realm initiator and decides whether to release BootSync data. In the second terminal, you'll run the Arm CCA FVP and launch Realm virtual machines using `lkvm-bootsync`. ## Install dependencies @@ -79,9 +81,9 @@ You'll be asked for a passphrase for the Secure Boot signing certificates. Remem ./run-user-context-service.sh ``` -## Verify BootSync without Secure Boot enabled +## Validate BootSync failure without boot data -With the User Context service running in one terminal, open up a new terminal in which you'll run CCA realms. +With the User Context service running in one terminal, open up a new terminal in which you'll run CCA Realms. Pull the Docker image with the pre-built FVP and CCA reference software stack. Then, run the container connected to the same Docker network: @@ -176,7 +178,7 @@ This is an intentional failure: BootSync completed enough of the protocol to req Next, you'll add the missing Boot Information Block data and repeat the launch. -## Enable Secure Boot and validate unsigned kernel rejection +## Pass UEFI variable data and validate unsigned kernel rejection On the terminal with the User Context service, stop the service by pressing `Ctrl-C`. @@ -318,7 +320,7 @@ poweroff You've successfully started a Realm with UEFI Secure Boot configured and enabled using Arm CCA BootSync. -## Encrypt the root file system and update the secret for disk unlock +## Encrypt the root file system and update secret data for disk unlock You can use the secret data shared with a Realm using Arm CCA BootSync to provide access to encrypted file systems. You'll now encrypt the root file system, observe a failed unlock when the wrong secret is available, and update the BootSync secret so the Realm can unlock the disk during boot. @@ -345,9 +347,9 @@ There are different ways to provide a Realm with access to encrypted partitions echo 'Booting Linux...' boot ``` - With the current Grub implementation of Arm CCA BootSync support, the booted operating system has access to the initramfs only. + With the current Grub implementation of Arm CCA BootSync support, the booted operating system has access to the `initramfs` only. -- Use an init script in an initrd image to unlock and mount the encrypted partition. You will use this approach in the next steps. +- Use an init script in an `initrd` image to unlock and mount the encrypted partition. You'll use this approach in the next step. {{% /notice %}} @@ -372,7 +374,7 @@ WARNING: keyslots area (1015808 bytes) is very small, available LUKS2 keyslot co Enable Initrd image ``` -### Validate the failed unlock +### Validate failed disk unlock Relaunch the Realm. At this point, `ARMCCA01_SEC.dat` still contains the test string from the previous Secure Boot step, not the disk encryption passphrase: @@ -425,7 +427,7 @@ poweroff The init script failed to unlock the encrypted partition because the Secret Data file doesn't contain the encryption passphrase yet. -### Update the BootSync secret and validate a successful unlock +### Update the BootSync secret and validate successful disk unlock Now, update the BootSync secret. @@ -505,4 +507,4 @@ poweroff You’ve now used Arm CCA BootSync to enable UEFI Secure Boot and unlock an encrypted root file system for a Realm. -You can extend the workflows covered in this Learning Path to your own Realm workloads. +You can extend the workflows covered in this Learning Path to provide trusted early-boot data for your own Realm workloads. From 5e03b66bd3a612101ed9a91e88a50e0e2cc44299 Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Fri, 17 Jul 2026 14:04:12 -0500 Subject: [PATCH 9/9] updating how terminals are referred to --- .../cca-bootsync/_index.md | 48 ++++++++++++++++++- .../cca-bootsync/flow.md | 37 +++++++------- 2 files changed, 67 insertions(+), 18 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md index 64218714f2..a2e2fbd538 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md @@ -16,11 +16,56 @@ prerequisites: - 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](/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)](/learning-paths/servers-and-cloud-computing/cca-container/) Learning Path +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-07-17T18:27:39Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 5b4a562e119669be2adcee1e0f304ca8cd2032cc5b6056ad01a88251019c010c + summary_generated_at: '2026-07-17T18:27:39Z' + summary_source_hash: 5b4a562e119669be2adcee1e0f304ca8cd2032cc5b6056ad01a88251019c010c + faq_generated_at: '2026-07-17T18:27:39Z' + faq_source_hash: 5b4a562e119669be2adcee1e0f304ca8cd2032cc5b6056ad01a88251019c010c + 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. + faqs: + - question: Do I need networking inside the Realm to deliver boot data? + answer: >- + No. BootSync operates before the guest operating system has networking and uses the Boot Injection protocol to provide early boot data. + - question: How do I know BootSync requested variable data? + answer: >- + In the User Context service log, you'll see `BIB Variable Data Requested` + and the expected `_VAR.dat` file name. If the file is missing, + BootSync reports `BootSyncNotDone`, and the Realm boots without Secure + Boot enabled. + - question: What result should I expect when Secure Boot is configured but the kernel is unsigned? + answer: >- + The unsigned kernel is rejected. This confirms that UEFI Secure Boot is enforcing signature + verification. + - question: After I sign the kernel, how do I verify that Secure Boot is enabled? + answer: >- + The signed kernel boots successfully and the Secure Boot UEFI variable reports `1`. Check + that value to confirm the state. + - question: How do I confirm the encrypted root file system unlocks correctly? + answer: >- + 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 `/`. +# END generated_summary_faq + author: - Anton Antonov - Pareena Verma -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false @@ -72,3 +117,4 @@ weight: 1 # _index.md always has weight of 1 to order corr layout: "learningpathall" # All files under learning paths have this same wrapper learning_path_main_page: "yes" # This should be surfaced when looking for related content. Only set for _index.md of learning path content. --- + diff --git a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md index a7baf79902..3a6fb44775 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/flow.md @@ -19,7 +19,10 @@ You'll configure and validate both failure and success cases: You'll run the User Context service in a Docker container and launch CCA Realms on an Arm Fixed Virtual Platform (FVP) in a separate Docker container. -You'll use two terminals. In the first terminal, you'll run the User Context service. This service represents the Realm initiator and decides whether to release BootSync data. In the second terminal, you'll run the Arm CCA FVP and launch Realm virtual machines using `lkvm-bootsync`. +You'll use two terminals: + +- In the User Context terminal, you'll run the User Context service. This service represents the Realm initiator and decides whether to release BootSync data. +- In the FVP terminal, you'll run the Arm CCA FVP and launch Realm virtual machines using `lkvm-bootsync`. ## Install dependencies @@ -53,11 +56,11 @@ Add your user name to the Docker group so you can run Docker without `sudo`: sudo usermod -aG docker $USER newgrp docker ``` -The group change applies to new shells; `newgrp docker` updates the current terminal. +The group change applies to new shells; `newgrp docker` updates the current shell. ## Start the User Context service -First, pull the Docker image with the pre-built User Context service. Then, run the container: +In the User Context terminal, pull the Docker image with the pre-built User Context service. Then, run the container: ```bash docker pull armswdev/cca-learning-path:cca-key-broker-v4 @@ -67,7 +70,7 @@ docker run --rm -it --network cca-trustee --name user-context armswdev/cca-learn The `cca-trustee` Docker network is important. It lets the FVP container resolve the User Context service by container name, `user-context`, when `lkvm-bootsync` later uses `--service-ip user-context`. -Now, within your running Docker container, start the User Context service using the `run-user-context-service.sh` script. +In the User Context terminal, start the User Context service inside the running container using the `run-user-context-service.sh` script. The User Context service is part of the [EDK2](https://gitlab.arm.com/linux-arm/edk2-cca/-/tree/cca/4441_measured_boot_v1/ArmVirtPkg/ArmCcaBootSync/UserContext) project. Created specifically as a proof of concept, it's intentionally small and not designed for production use. @@ -83,7 +86,7 @@ You'll be asked for a passphrase for the Secure Boot signing certificates. Remem ## Validate BootSync failure without boot data -With the User Context service running in one terminal, open up a new terminal in which you'll run CCA Realms. +With the User Context service running in the User Context terminal, open the FVP terminal. Pull the Docker image with the pre-built FVP and CCA reference software stack. Then, run the container connected to the same Docker network: @@ -163,7 +166,7 @@ Stop the Realm: poweroff ``` -On the terminal with the User Context service, you can see that the Realm firmware requested a Variable Data file, but the file is missing: +In the User Context terminal, you can see that the Realm firmware requested a Variable Data file, but the file is missing: ```output INFO: BIB Variable Data Requested @@ -180,7 +183,7 @@ Next, you'll add the missing Boot Information Block data and repeat the launch. ## Pass UEFI variable data and validate unsigned kernel rejection -On the terminal with the User Context service, stop the service by pressing `Ctrl-C`. +In the User Context terminal, stop the service by pressing `Ctrl-C`. The RPV and file names used here are details of this Learning Path's reference implementation. One User Context service can support multiple Realms by using the RPV as a file-name prefix. A Realm launched with `--realm-pv ARMCCA01` requests files that start with `ARMCCA01`. If the matching files are missing, BootSync can establish a session and complete attestation, but the User Context can't provide the requested boot information. @@ -197,13 +200,13 @@ Create a Secret Data file with a test string that'll be shared with a Realm usin echo "My Realm secret data" > SecureBoot/ARMCCA01_SEC.dat ``` -Relaunch the User Context service: +In the User Context terminal, relaunch the User Context service: ```bash ./run-user-context-service.sh ``` -On the terminal with FVP, relaunch the Realm with the same RPV: +In the FVP terminal, relaunch the Realm with the same RPV: ```bash cd /cca @@ -218,7 +221,7 @@ cd /cca Keeping the same `--realm-pv ARMCCA01` is what links the Realm request to the files you created. -On the terminal with the User Context service, you can see that attestation succeeded and BootSync completed: +In the User Context terminal, you can see that attestation succeeded and BootSync completed: ```output Info: Received FIN. Disconnecting. @@ -247,7 +250,7 @@ Next, you'll launch a Realm with a signed kernel image. ## Sign the kernel and verify Secure Boot -On the terminal with FVP, use the `sign_guest_kernel.sh` script to sign the Realm Linux kernel with the Secure Boot certificate generated earlier by the User Context setup script. When prompted, enter the passphrase you used for the Secure Boot signing certificates: +In the FVP terminal, use the `sign_guest_kernel.sh` script to sign the Realm Linux kernel with the Secure Boot certificate generated earlier by the User Context setup script. When prompted, enter the passphrase you used for the Secure Boot signing certificates: ```bash { output_lines="2-3" } sign_guest_kernel.sh @@ -256,7 +259,7 @@ Enter PEM pass phrase: Signing Unsigned original image ``` -Relaunch the Realm. Use the same User Context service, service port, and RPV so the Realm receives the same Secure Boot variable data: +In the FVP terminal, relaunch the Realm. Use the same User Context service, service port, and RPV so the Realm receives the same Secure Boot variable data: ```bash cd /cca @@ -353,7 +356,7 @@ There are different ways to provide a Realm with access to encrypted partitions {{% /notice %}} -On the terminal with the running FVP, use the `encrypt_rootfs.sh` script to encrypt the root partition in the Realm disk image and add an `initrd` image to the kernel parameters. +In the FVP terminal, use the `encrypt_rootfs.sh` script to encrypt the root partition in the Realm disk image and add an `initrd` image to the kernel parameters. You'll be asked for a passphrase to encrypt the root partition. Use a memorable test passphrase and keep it available, because you'll later write the same value into `ARMCCA01_SEC.dat` for BootSync to release. @@ -376,7 +379,7 @@ Enable Initrd image ### Validate failed disk unlock -Relaunch the Realm. At this point, `ARMCCA01_SEC.dat` still contains the test string from the previous Secure Boot step, not the disk encryption passphrase: +In the FVP terminal, relaunch the Realm. At this point, `ARMCCA01_SEC.dat` still contains the test string from the previous Secure Boot step, not the disk encryption passphrase: ```bash cd /cca @@ -431,7 +434,7 @@ The init script failed to unlock the encrypted partition because the Secret Data Now, update the BootSync secret. -On the terminal with the User Context service, stop the service by pressing `Ctrl-C`. +In the User Context terminal, stop the service by pressing `Ctrl-C`. Save the encryption passphrase into the Secret Data file. Use `echo -n` so the file contains only the passphrase and no trailing newline character: @@ -440,13 +443,13 @@ ROOTFS_PASSPHRASE='replace-with-the-passphrase-you-used-for-encrypt_rootfs' echo -n "$ROOTFS_PASSPHRASE" > SecureBoot/ARMCCA01_SEC.dat ``` -Relaunch the User Context service: +In the User Context terminal, relaunch the User Context service: ```bash ./run-user-context-service.sh ``` -On the terminal with FVP, relaunch the Realm with the same RPV: +In the FVP terminal, relaunch the Realm with the same RPV: ```bash cd /cca