Merge pull request #3469 from pareenaverma/content_review

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 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.
 
 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 the Boot Injection Protocol"
 
 weight: 2 # 1 is first, 2 is second, etc.
 
@@ -10,12 +10,43 @@ 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 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:
 
-- [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.
+
+## Boot Injection Protocol 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.
+
+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.