Addressing feedback comments from Anton

Author: pareenaverma

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

@@ -12,7 +12,7 @@ who_is_this_for: This Learning Path is for developers who want to understand how
 
 learning_objectives:
   - 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.
+  - 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.
 

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 Sync Blocks protocol"
+title: "Overview of Arm CCA BootSync and the Boot Injection Protocol"
 
 weight: 2 # 1 is first, 2 is second, etc.
 
@@ -12,7 +12,7 @@ layout: "learningpathall"
 
 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.
 
-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:
+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:
 
 - Variable data, such as UEFI variables used to configure Secure Boot.
 - Secret data, such as a disk unlock passphrase or other boot-time secret.
@@ -30,21 +30,19 @@ 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.
 
-## BootSync protocol stages
+## Boot Injection Protocol stages
 
-The BSB 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 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.
+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 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.
+- 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.

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

@@ -69,7 +69,7 @@ It has been created specifically for POC purposes, so is intentionally small and
 
 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 UEFI variable definitions required for enabling Secure Boot.
+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.
 
@@ -143,7 +143,7 @@ realm login: root
 (realm) #
 ```
 
-Use the `efivar` utility to check the Secure Boot UEFI variable. A value of `0` confirms that Secure Boot is not enabled:
+Use the `efivar` utility to check the Secure Boot EFI variable. A value of `0` confirms that Secure Boot is not enabled:
 
 ```bash { output_lines="3" }
 mount -t efivarfs efivarfs /sys/firmware/efi/efivars
@@ -175,6 +175,8 @@ In the next step, you will add the missing Boot Information Block data and repea
 
 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.
+
 Copy the generated Provisioning Data file to a Realm variable data file with the name `<RPV>_VAR.dat`. Because you launched the Realm with `--realm-pv ARMCCA01`, the User Context service looks for `ARMCCA01_VAR.dat`:
 
 ```bash
@@ -187,7 +189,7 @@ Create a Secret Data file with data that will be shared with a Realm using the s
 echo "My Realm secret data" > SecureBoot/ARMCCA01_SEC.dat
 ```
 
-Start the User Context service again so it can load the new `ARMCCA01_VAR.dat` and `ARMCCA01_SEC.dat` files:
+Relaunch the User Context service:
 
 ```bash
 ./run-user-context-service.sh
@@ -273,7 +275,7 @@ realm login: root
 (realm) #
 ```
 
-Use `efivar` to check the Secure Boot UEFI variable. A value of `1` confirms that Secure Boot is enabled:
+Use `efivar` to check the Secure Boot EFI variable. A value of `1` confirms that Secure Boot is enabled:
 
 ```bash { output_lines="3" }
 mount -t efivarfs efivarfs /sys/firmware/efi/efivars
@@ -416,7 +418,7 @@ ROOTFS_PASSPHRASE='replace-with-the-passphrase-you-used-for-encrypt_rootfs'
 echo -n "$ROOTFS_PASSPHRASE" > SecureBoot/ARMCCA01_SEC.dat
 ```
 
-Start the User Context service again so it reloads the updated Secret Data file:
+Relaunch the User Context service:
 
 ```bash
 ./run-user-context-service.sh