Arm CCA BootSync LP review

content/learning-paths/servers-and-cloud-computing/cca-bootsync/_index.md

@@ -1,30 +1,71 @@
 ---
-title: Arm 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.
+title: Secure Realms during boot using Arm Confidential Compute Architecture (CCA) BootSync
+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.
 
-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.
+  - 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 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/)
+  - 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 `<RPV>_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
 
@@ -36,7 +77,6 @@ armips:
   - Cortex-A
 operatingsystems:
   - Linux
-  - macOS
 tools_software_languages:
   - FVP
   - RME
@@ -77,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.
 ---
+

content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md

@@ -1,52 +1,48 @@
 ---
 # User change
-title: "Overview of 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.
 
 # Do not modify these elements
 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 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. In this Learning Path, you use BootSync to provide two kinds of data to a Realm:
+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:
 
 - 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.
 
-## Component roles
+## Components of the BootSync flow
 
 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.
 
-## Boot Injection Protocol stages
+## 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.
 3. Boot Information Blocks carry the requested boot data after attestation succeeds.
 
-## What you will validate
-
-The exercises intentionally show 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.
+## What you've learned and what's next
 
-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/).
+You’ve learned how Arm CCA BootSync uses key exchange, attestation, and Boot Information Blocks to provide trusted data during Realm boot.
 
-In the next section, you will launch Realms and see how Arm CCA BootSync can inject UEFI variables and secret data during early boot.
+Next, you'll launch Realms and see how Arm CCA BootSync can inject UEFI variables and secret data during early boot.