Tech review and added context to CCA BootSync LP

Author: pareenaverma

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

@@ -1,23 +1,24 @@
 ---
-title: Arm CCA Boot Sync
-description: Learn how to use Arm CCA Boot Sync while launching Arm CCA Realms on an FVP with RME support.
+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.
 
 draft: true
 cascade:
     draft: true
 
 minutes_to_complete: 60
 
-who_is_this_for: This Learning Path is for developers who want to understand how to use Arm CCA Bootsync.
+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:
-  - Gain an overview of Arm CCA Boot Sync and Boot Onjection Protocol.
-  - Understand how Arm CCA Boot Sync can be used for defining UEFI variables, enabling Secure Boot and share secure data with Arm CCA Realms.
-  - Lanch Arm CCA Realms with Secure Boot enabled and encrypted file system using an Armv9-A AEM Base Fixed Virtual Platform (FVP) with RME support.
+  - Explain why BootSync is needed before the Realm guest operating system has networking.
+  - Describe how the Boot Sync Blocks protocol uses key exchange, attestation, and Boot Information Blocks.
+  - 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.
 
 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/)
-  - 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
+  - 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:
   - Anton Antonov
@@ -61,11 +62,18 @@ further_reading:
       title: Realm Management Monitor Specification
       link: https://developer.arm.com/documentation/den0137/latest/
       type: documentation
+  - resource:
+      title: Realm Host Interface Specification
+      link: https://developer.arm.com/documentation/den0148/latest/
+      type: documentation
+  - resource:
+      title: ArmCcaBootSync README
+      link: https://gitlab.arm.com/linux-arm/edk2-cca/-/blob/cca/4441_measured_boot_v1/ArmVirtPkg/ArmCcaBootSync/Readme.md
+      type: documentation
 
 ### FIXED, DO NOT MODIFY
 # ================================================================================
 weight: 1                       # _index.md always has weight of 1 to order correctly
 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,6 +1,6 @@
 ---
 # User change
-title: "Overview of Arm CCA BootSync and Boot Injection protocol"
+title: "Overview of Arm CCA BootSync and Boot Sync Blocks protocol"
 
 weight: 2 # 1 is first, 2 is second, etc.
 
@@ -10,12 +10,45 @@ layout: "learningpathall"
 
 ## Design overview
 
-TO_DO: Explain Boot Injection protocol and Arm CCA Boot Sync wokflow.
+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.
 
-For more details see:
+The reference implementation uses the *Boot Sync Blocks* (BSB) protocol described by the Realm Host Interface (RHI) specification. In this Learning Path, you use BootSync to provide two kinds of data to a Realm:
 
-- [ArmCcaBootSync/Readme.md](https://gitlab.arm.com/linux-arm/edk2-cca/-/blob/cca/4441_measured_boot_v1/ArmVirtPkg/ArmCcaBootSync/Readme.md)
-- Appendix A (Boot Injection) in [the RHI specifications document](https://confluence.arm.com/display/FENIMORE/RHI+specification)
+- 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.
 
-In the next section, you will launch realms and see how Arm CCA BootSync can be used.
+## Component roles
+
+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 *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.
+
+## BootSync protocol stages
+
+The BSB 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 release the requested boot data after attestation succeeds. In this Learning Path, those blocks are represented by files whose names begin with the Realm Personalization Value (RPV), such as `ARMCCA01_VAR.dat` and `ARMCCA01_SEC.dat`.
+
+The RPV is important because one User Context service can support multiple Realms. 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 it cannot provide the requested boot information.
+
+## What you will validate
+
+The exercises intentionally show both failure and success cases:
+
+- First, you launch a Realm without the variable data file. This demonstrates that the firmware can ask for BootSync data and that the User Context reports a missing `ARMCCA01_VAR.dat` file.
+- 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.
+
+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.