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 37ceacb08a..306d47b171 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: 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: @@ -8,16 +8,17 @@ cascade: 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,6 +62,14 @@ 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 # ================================================================================ @@ -68,4 +77,3 @@ 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/cca-bootsync.md b/content/learning-paths/servers-and-cloud-computing/cca-bootsync/cca-bootsync.md index a0bc90e1e1..bd61e6f726 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 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. 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 23306e8206..34f9849017 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: "Arm CCA Boot Sync" +title: "Arm CCA BootSync" weight: 3 # 1 is first, 2 is second, etc. @@ -9,15 +9,18 @@ layout: "learningpathall" --- ## Overview -In this section you will run the **User Context** service in a docker container, -launch a **CCA realm** on **Arm FVP** running in a separate docker container -and see how Arm CCA BootSync can be used to define realm EFI variables and share secret data with realms. -You will also see how the defined EFI variables can be used to enable UEFI Secure Boot and -the shared secret data can be used for providing access to encrypted file systems. +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. + +The flow 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`. + +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. ## Install dependencies -Start by installing Docker. On Ubuntu 24.04 LTS, set up Docker’s APT repository: +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: ```bash # Add Docker's official GPG key: @@ -35,22 +38,24 @@ echo \ sudo apt-get update ``` -Install Git and Docker packages: -``` +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: + +```bash 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 (open a new shell after this so the change takes effect): -``` bash +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: + +```bash sudo usermod -aG docker $USER newgrp docker ``` ## Start User Context service -First, pull the docker container image with the pre-built User Context service, and then run the container. -Running the container with specified name and network, would allow later to connect to the services running in the -container using the container name as a host name. +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`. ```bash docker pull armswdev/cca-learning-path:cca-key-broker-v4 @@ -58,25 +63,25 @@ 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 User Context service using `run-user-context-service.sh` script. +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. -When started first time the script would generate SecureBoot signing certificates and create a Provisioning Data file. +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 variables defintions required for enabling SecureBoot. +The file contains EFI variable definitions required for enabling UEFI Secure Boot. -You will be asked for a passphrase which will be used for Secure boot signing certificates. +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. ```bash ./run-user-context-service.sh ``` -## Launch a CCA Realm without SecureBoot enabled. +## 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. -Pull the Docker image with the pre-built FVP, 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, and then run the container connected to the same Docker network: ```bash docker pull armswdev/cca-learning-path:cca-simulation-v4 @@ -102,9 +107,12 @@ host login: root ``` Change directory to `/cca` and use `lkvm-bootsync` to launch a guest Linux in a Realm. -In the command line paramaters we specify "user-context" as the User Context service host name, -its default port and Realm Personalisation value (RPV). -RPV is a user-provided byte string (up to 64 bytes) that allows you to distinguish between Realms. + +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`. ```bash cd /cca @@ -119,7 +127,7 @@ cd /cca You should see the realm boot. -In the realm boot output you can see that UEFI Secure Boot is not mentioned in EFI messages: +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,9 +143,9 @@ realm login: root (realm) # ``` -Using `efivar` utility you can check EFI variables to confirm 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" } +```bash { output_lines="3" } mount -t efivarfs efivarfs /sys/firmware/efi/efivars efivar -p -d -n {global}-SecureBoot 0 @@ -149,10 +157,9 @@ Stop the realm: poweroff ``` -On the terminal with the User Context service you can see that during boot the realm firmware -requested a Variable Data file which is missing. As a result the BootSync procedure failed. +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. -``` output +```output INFO: BIB Variable Data Requested FileName = ARMCCA01_VAR.dat Error: ARMCCA01_VAR.dat Not found! @@ -162,28 +169,34 @@ Info: Attestation State: AttSuccess Info: BootSync State: BootSyncNotDone ``` -In the next step we will fix the BootSync procedure. +In the next step, you will add the missing Boot Information Block data and repeat the launch. -## Launch a CCA Realm with SecureBoot enabled. +## Launch a CCA Realm with Secure Boot enabled On the terminal with the User Context service stop the service by pressing `Ctrl-C`. -Copy the generated Provisioning Data file to a realm Variable data file with a name `_VAR.dat`: -``` bash +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 `_VAR.dat`. Because you launched the Realm with `--realm-pv ARMCCA01`, the User Context service looks for `ARMCCA01_VAR.dat`: + +```bash cp SecureBoot/SecBootCert/pd.bin SecureBoot/ARMCCA01_VAR.dat ``` -Create a Secret Data file with some secret data which will be shared with a realm with the same RPV: -``` bash +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: + +```bash echo "My Realm secret data" > SecureBoot/ARMCCA01_SEC.dat ``` -Start User Context service: +Relaunch the User Context service: + ```bash ./run-user-context-service.sh ``` -On the terminal with FVP, relaunch the realm: +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: + ```bash cd /cca ./lkvm-bootsync run --realm --disable-sve --irqchip=gicv3-its \ @@ -195,43 +208,43 @@ cd /cca --realm-pv ARMCCA01 ``` -On the terminal with the User Context service you can see that the attestation was successfull and -BootSync completed: -``` outout +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: + +```output Info: Received FIN. Disconnecting. Info: Session State: UnConnected Info: Attestation State: AttSuccess Info: BootSync State: BootSyncCompete ``` -But, the realm would fail to boot Linux kernel: -``` output +The Realm now fails to boot the Linux kernel: + +```output 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: -``` bash + +```bash reset ``` -Linux kernel successfully booted in the realm without SecureBoot enabled, -but failed to boot after you enabled SecureBoot. This happened because we are using a realm file system image -with an unsigned kernel. You will fix it in the next step. +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. -## Launch a CCA Realm with SecureBoot enabled and a signed Linux kernel +## Launch a CCA Realm with Secure Boot enabled and a signed Linux kernel -On the terminal with FVP use `sign_guest_kernel.sh` script to sign realm Linux kernel. -You will be asked for the passphrase you used for 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. You will be asked for the passphrase you used for the Secure Boot signing certificates. -```bash { output_lines = "2-3" } +```bash { output_lines="2-3" } sign_guest_kernel.sh Signing kernel image: Enter PEM pass phrase: Signing Unsigned original image ``` -Relaunch the realm: +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 ./lkvm-bootsync run --realm --disable-sve --irqchip=gicv3-its \ @@ -243,9 +256,9 @@ cd /cca --realm-pv ARMCCA01 ``` -You should see the realm boot. +You should see the Realm boot. -In the realm boot output you can see in EFI messages that UEFI Secure Boot is enabled: +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... @@ -254,7 +267,7 @@ EFI stub: Generating empty DTB EFI stub: Exiting boot services... ``` -After the realm boots, log in, using the root again as the username: +After the Realm boots, log in using `root` as the username: ```output Welcome to the CCA realm @@ -262,24 +275,25 @@ realm login: root (realm) # ``` -Using `efivar` utility you can check EFI variables to confirm 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" } +```bash { output_lines="3" } mount -t efivarfs efivarfs /sys/firmware/efi/efivars efivar -p -d -n {global}-SecureBoot 1 ``` You can also see that EFI SetupMode is disabled: -```bash { output_lines = "2" } + +```bash { output_lines="2" } 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 which is shared with the realm using GRUB_EFI_DISKPASSWD_GUID: +access the secret data shared with the Realm. In this demo, the data is exposed under the `GRUB_EFI_DISKPASSWD_GUID` entry: -```bash { output_lines = "3" } +```bash { output_lines="3" } mount -t securityfs none /sys/kernel/security cat /sys/kernel/security/secrets/coco/736869e5-84f0-4973-92ec-06879ce3da0b My Realm secret data @@ -293,13 +307,13 @@ poweroff You have 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. +## Launch a CCA Realm with an encrypted root file system - The secure data shared with realm via Arm CCA BootSync can also be used to provide access to encrypted file systems. +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. {{% notice Access to encrypted partitions %}} -There are different ways you can use to provide realm with access to encrypted partitions using Arm CCA Bootsync. For example: +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. @@ -317,23 +331,23 @@ initrd (crypto0)/initrd.gz echo 'Booting Linux...' boot ``` -Please notice that with the current Grub implementation of Arm CCA BootSync support booted OS will have access to the -Init ramdisk 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 stages. +- 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 running FVP use `encrypt_rootfs.sh` script to encrypt the root partition in the realm disk image and -add an initrd image into the kernel parameters. -You will be asked for an passphrase which will be used for the encryption. +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 can use maximum of 512 characters of upper/lowercase, numbers and symbols. -You can ignore the WARNING message because we're using small size paritions for this demo. +You can ignore the warning message because this demo uses small partitions. -```bash { output_lines = "2-11" } +```bash { output_lines="2-11" } encrypt_rootfs.sh -Resizing root file system to accomodate minimal LUKS2 header +Resizing root file system to accommodate minimal LUKS2 header resize2fs 1.47.3 (8-Jul-2025) Resizing the filesystem on /dev/loop0p2 to 260096 (1k) blocks. The filesystem on /dev/loop0p2 is now 260096 (1k) blocks long. @@ -345,7 +359,8 @@ WARNING: keyslots area (1015808 bytes) is very small, available LUKS2 keyslot co Enable Initrd image ``` -Relaunch the realm: +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 ./lkvm-bootsync run --realm --disable-sve --irqchip=gicv3-its \ @@ -372,16 +387,16 @@ 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 you can check that only Init ramdisk is mounted and you can't mount `/dev/vda2`: +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: -```bash { output_lines = "2-3" } +```bash { output_lines="2-3" } df -h Filesystem Size Used Available Use% Mounted on devtmpfs 174.4M 0 174.4M 0% /dev ``` -```bash { output_lines = "2" } +```bash { output_lines="2" } mount -t auto /dev/vda2 /cryptroot mount: mounting /dev/vda2 on /cryptroot failed: Invalid argument ``` @@ -392,22 +407,25 @@ Stop the realm: poweroff ``` -The Init script failed to unlock the encrypted partition because we have not shared the encryption passphrase with the realm. -Let's fix that. +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. On the terminal with the User Context service stop the service by pressing `Ctrl-C`. -Save the encryption passpharse into the Secret Data file. Please use `-n` parameter to exclude the trailing newline character. -``` bash -echo -n "" > SecureBoot/ARMCCA01_SEC.dat +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' +echo -n "$ROOTFS_PASSPHRASE" > SecureBoot/ARMCCA01_SEC.dat ``` -Start User Context service: +Relaunch the User Context service: + ```bash ./run-user-context-service.sh ``` -On the terminal with FVP, relaunch the realm: +On the terminal with FVP, relaunch the Realm with the same RPV: + ```bash cd /cca ./lkvm-bootsync run --realm --disable-sve --irqchip=gicv3-its \ @@ -419,7 +437,7 @@ cd /cca --realm-pv ARMCCA01 ``` -In the realm boot log you can see that the Init script successfully unlocked and mounted the encrypted partition: +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 @@ -428,7 +446,7 @@ Detecting LUKS containers in vda1-2 *** LUKS partition unlocked, switching root *** ``` -After the realm boots, log in, using the root again as the username: +After the Realm boots, log in using `root` as the username: ```output Welcome to the CCA realm @@ -436,9 +454,9 @@ realm login: root (realm) # ``` -You can check that the unlocked encrypted partition `/dev/mapper/cryptroot` mounted as root. +Check that the unlocked encrypted partition `/dev/mapper/cryptroot` is mounted as root: -```bash { output_lines = "2-9" } +```bash { output_lines="2-9" } df -h Filesystem Size Used Available Use% Mounted on devtmpfs 174.4M 0 174.4M 0% /dev