Boot process

Note

The Safety Island Cluster 1 (SI CL1) is present only in the FVP CFG2 variant.

RSE-oriented boot flow

The RSE is the root of trust chain. It is the first booting element when the system is powered up.

The boot sequence is shown in the RSE-oriented Boot Flow diagram in the Measured Boot section.

The RSE flash is used to store the images of various components, including:

• RSE BL2 image

• RSE Runtime image

• Safety Island Cluster 0 (SI0 RAMFW) image

• Safety Island Cluster 1 (SI CL1) image

RSE uses the Application Processor secure flash for:

• Application Processor BL2 (AP BL2) image

Images layout

rse-otp-image.img and rse-rom-image.img are raw, partition-less image blobs. rse-flash-image.img, ap-flash-image.img and *.wic are GPT partitioned images. *.wic contains a fat16 partition (UEFI boot infrastructure, systemd-boot, Linux) and an ext4 partition (minimal rootfs). The wic file name depends on the use case which has been built. For example, for the baremetal use cases the file is named baremetal-image-fvp-rd-aspen.wic.

The following table summarizes the storage media into which each image is loaded by the FVP:

Image	Storage medium
rse-otp-image.img	RSE OTP
rse-rom-image.img	RSE ROM
rse-flash-image.img	RSE flash
ap-flash-image.img	AP secure flash
*.wic	VirtIO block 0

The following image shows the internal layout of the different images:

Fig. 26 Layout of the Generated Images

Chain of Trust (CoT)

To maintain platform security, each image in the boot flow must be validated for authenticity and integrity. This is achieved by establishing a Chain of Trust, in which every stage in the execution sequence authenticates the next stage before it runs. Image authentication uses hash verification and digital signature validation to ensure that only trusted software is executed.

Image signing

An RSA private key is stored in TF-M’s source code repository (the bl2/ext/mcuboot/root-RSA-3072.pem file) for testing. The private key is used to sign the images listed above that RSE BL2 loads.

In the Yocto build stage of the platform, a shell function sign_host_image() is used to sign the images, which can be found at meta-arm/classes/tfm_sign_image.bbclass. Then the signed images are written to RSE flash and AP Secure flash.

System provisioning and image authentication

A public key is derived from the private key for authenticating the signed images. The public key is also known as the Root of Trust Public Key (ROTPK). It is also written in the AP secure flash in the build stage.

During the system’s first boot, the hash of the public key is provisioned into the OTP by BL1_1. When the provisioning stage has been completed, the OTP contents cannot be updated.

RSE BL2 reads the public key from the AP secure flash and validates the public key against the hash that has been provisioned in the OTP. Then RSE BL2 uses the public key to authenticate the images.

Note

In the current implementation, only the RSE BL2 image is decrypted and authenticated, while the SI CL0 and SI CL1 image are stored without encryption, so they are only authenticated. Future releases will include support for the decryption, authentication, and measurement of all images.

Key customization

The default private key used in the CSS-Aspen platform must only be used for test purposes. Because this private key is widely distributed, it must never be used for production. To replace the default key, you need to:

• Generate a new RSA key pair

• Replace the default private key bl2/ext/mcuboot/root-RSA-3072.pem with the new private key

For details of how to generate the private key, see the documentation of imgtool which is provided by MCUboot.

Measured Boot

Measured Boot computes and securely records hashes of code and critical data at every point in the boot chain before that code or data is executed or accessed. Other system components can then rely on these measurements to build a full attestation solution, e.g., to enforce local attestation policies (releasing specific platform keys or not) or to transmit the measurements to a remote verifier after boot, proving the code-and-data state. Measured Boot itself does not authenticate the code or data; it merely records what was present during boot.

After RSE reaches its runtime and starts booting the remainder of the system, it supplies measured boot and attestation services to the AP. The RSE runtime first gathers the measurements stored by earlier RSE stages via the offline measured boot APIs, which are available before RSE runtime is up, see boot_store_measurement(). When AP finishes each of its boot stages, it sends the corresponding measurements over MHU through the online measured boot APIs provided by the RSE runtime, see measured_boot_extend_measurement(). All captured measurements reside in RSE internal SRAM and are marked immutable until software policy resets them. Finally, the AP can obtain the completed attestation token via the attestation API, see initial_attest_get_token(). For reference regarding Measured Boot, see TF-M Measured Boot integration guide. For reference regarding Initial Attestation, see TF-M Initial Attestation integration guide. The following table shows the values that can be included into the measurement and a short description of their purpose:

Key ID	Type	Required	Description
1	Measurement type	No	A short string representing the role of this software component
2	Measurement value	Yes	Represents a hash of the invariant software component in memory at startup time. The value must be a cryptographic hash of 256 bits or stronger.
3	Reserved	No	Reserved
4	Version	No	The issued software version in the form of a text string. The value of this claim corresponds to the entry in the original signed manifest of the component.
5	Signer ID	No	The hash of a signing authority public key for the software component. The value of this claim corresponds to the entry in the original manifest for the component.
6	Measurement description	No	Description of the software component, which represents the way in which the measurement value of the software component is computed. The value is a text string containing an abbreviated description (or name) of the measurement method, which can be used to look up the details of the method in a profile document.

The current implementation in CSS-Aspen uses measured boot with the following assumptions:

• RSE BL1_1 is RoT, it is not measured.

• All boot images up to and including AP BL33 are measured. Later images, such as the Linux kernel, are not measured.

• Configuration data is not measured.

• Each measurement is extended into a unique, non-reused slot. Once used, a slot is locked immediately.

• Measurements are securely stored using the RSE as the storage backend.

• TF-A extends measurements via TF-M interface to the measured boot service, which handles storage in RSE.

• Measurements are performed only during boot. No runtime measurement is supported.

Measured by	Image	Slot	Hashing Algo
RSE BL1_1	RSE BL1_2	0	SHA256
RSE BL1_2	RSE BL2	1	SHA256
RSE BL2	RSE Runtime	2	SHA256
RSE BL2	AP BL2	4	SHA256
RSE BL2	SI CL0	5	SHA256
RSE BL2	SI CL1	6	SHA256
AP BL2	AP BL31	10	SHA256
AP BL2	AP BL32	11	SHA256
AP BL2	AP BL33	12	SHA256

Boot Flow

The following diagram illustrates the boot flow that originates from RSE.

Fig. 27 RSE-Oriented Boot Flow

Major steps of the boot flow:

1. RSE BL1_1:

   • Begins executing in place from ROM when the system is powered up

   • Provisions RSE BL1_2 and various keys and other data from the provisioning bundle to the OTP (this step only happens on the system’s first boot)

   • Copies the RSE BL1_2 image from the OTP to the RSE SRAM

   • Validates RSE BL1_2 against the hash stored in the OTP

   • Computes RSE BL1_2 image measurement

   • Transfers the execution to RSE BL1_2

2. RSE BL1_2:

   • Copies the encrypted RSE BL2 image from the RSE flash into the RSE SRAM

   • Decrypts the RSE BL2 image

   • Validates the RSE BL2 image

   • Computes RSE BL2 image measurement

   • Transfers the execution to RSE BL2

3. RSE BL2:

   • If CFG2, copies the SI CL1 image from the RSE flash to SI LLRAM and authenticates the image

   • If CFG2, computes SI CL1 image measurement

   • Copies the SI CL0 image from the RSE flash to SI LLRAM and authenticates the image

   • Computes SI CL0 image measurement

   • Powers on the SI CL0; SI CL0 then turns on SI CL1, if it is present (CFG2)

   • Copies the Application Processor (AP) BL2 image from AP secure flash to AP shared SRAM

   • Computes AP BL2 image measurement

   • Copies RSE Runtime image from the RSE flash to the RSE SRAM

   • Computes RSE Runtime image measurement

   • Sends notification to SI CL0 that SCP-firmware can turn on AP

   • Jumps to RSE Runtime in the RSE SRAM

Primary Compute boot flow

The AP refers to the cores in the Primary Compute of the CSS-Aspen design. The purpose of its firmware is to provide an interface to boot Linux. Arm SystemReady Devicetree compatible systems are required to follow the Devicetree specification. The U-Boot bootloader is used in Normal world execution to provide the UEFI firmware interface, which loads the boot manager systemd-boot and exposes its device tree to the Linux kernel.

Trusted Firmware-A provides the initial Secure world firmware, consisting of BL2 and BL31. The BL32 is provided by OP-TEE. The BL33 is provided by U-Boot.

The Primary Compute uses:

• AP Secure flash containing the following components:

  • AP BL31

  • AP BL32 (OP-TEE)

  • AP BL33 (U-Boot)

• First VFAT (boot) partition of the VirtIO Block containing the following components:

  • systemd-boot

  • Linux kernel Image

  In case of Virtualization Architecture, this VirtIO Block additionally includes configuration files for Xen boot. The systemd-boot menu contains a config file which defines the Xen boot entry. This configuration specifies:

  • The Xen hypervisor binary (xen.efi)

  • The Dom0 Linux kernel Image

  • Xen command-line parameters (e.g., console settings, memory assignments, and DomU configuration options)

The Primary Compute boot flow follows the following steps:

1. AP BL2:

   • Copies Device Tree Blob (DTB) from AP Secure flash to Normal DRAM

   • Copies the AP BL31 image from the AP Secure flash to Secure SRAM

   • Computes AP BL31 image measurement and invokes extend operation of TF-M Measured Boot secure partition

   • Copies the AP BL32 (OP-TEE) image from the AP Secure flash to Secure DRAM

   • Computes AP BL32 image measurement and invokes extend operation of TF-M Measured Boot secure partition

   • Copies the AP BL33 (U-Boot) image from the AP Secure flash to Normal DRAM

   • Computes AP BL33 image measurement and invokes extend operation of TF-M Measured Boot secure partition

   • Transfers the execution to AP BL31

2. AP BL31:

   • Transfers the execution to AP BL32

   • Transfers the execution to AP BL33

3. AP BL33 loads systemd-boot from the boot partition

4. In case of Baremetal Architecture, systemd-boot loads and boots the Linux kernel from the boot partition.

   In case of Virtualization Architecture, the following steps are followed:

   • systemd-boot provides a boot entry for Xen and loads the Xen hypervisor binary along with the associated Dom0 kernel.

   • Xen sets up CPU, memory, and interrupt management, and then transitions to load Dom0 (the first and privileged domain). Dom0 is a Linux kernel image.

   • Once Dom0 is fully operational, it uses the Xen toolstack to start additional guest domains such as DomU1 and DomU2. Each DomU runs its own guest OS and is isolated from other domains by the Xen hypervisor.

Trusted Board Boot (TBB)

The Trusted Board Boot (TBB) feature ensures that only authenticated TF-A stages and configs up to and including the AP BL33 bootloader are allowed to run on the platform. It achieves this by establishing a Chain of Trust to prevent the execution of malicious firmware.

The TBB Chain of Trust (CoT) starts with a set of implicitly trusted components. On CSS-Aspen, these components are:

• RSE - Root of Trust for the CSS-Aspen platform.

  TF-M BL2 on RSE performs initial authentication and loading of AP BL2 image.

• A SHA-256 hash of the Root of Trust Public Key (ROTPK).

  CSS-Aspen uses a ROTPK derived from a development private key plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem. The hash of ROTPK is embedded in AP BL2 image.

Note

The development private key used in the CSS-Aspen platform TBB must only be used for test purposes. It must never be used for production.

The remaining components in the CoT are certificates and boot loader images. The certificates follow the X.509 V3 standard. It supports adding custom extensions to the certificates, which are used to store essential information to establish the CoT.

Trusted board boot also enforces rollback protection using non-volatile (NV) counters. This is to ensure that only firmware with version equal to or higher than the last authenticated image is allowed to boot.

See the Trusted Board Boot Requirements (TBBR) and Trusted Board Boot (TBB) documentation to learn about the TBB implementation.

UEFI Secure Boot

Note

The UEFI Secure Boot feature is enabled for baremetal use cases only.

The Reference Software Stack implements UEFI Secure Boot as a verification method to ensure that only trusted software is booted by the BL33 bootloader during the boot process. It establishes trust relationships between the platform owner, platform firmware and operating systems. This mitigates malicious or tampered software.

In the Reference Software Stack, UEFI Secure Boot is implemented through the provisioning and enrollment of authenticated variables. These authenticated variables are:

• Platform Key (PK): PK is the key pair used to create and verify digital signatures. The private key is owned by the platform owner, typically stored off-device, and used to create digital signatures for UEFI executables, as well as enroll the Key Exchange Keys. It establishes the trust relationship between the platform and the platform owner. The public key is enrolled in the platform firmware and used to verify digital signatures.

• Key Exchange Key (KEK): KEK signs and verifies writes to the Authorized and Forbidden Signature Databases. It establishes a trust relationship between the operating system and platform firmware, allowing the secure interchange of key information between the two.

• Authorized Signature Database (db): db contains the list of signatures of trusted software which can be executed during the boot process.

• Forbidden Signature Database (dbx): dbx contains the list of signatures that are no longer trusted to prevent software with these signatures from being executed. If the signature of a binary is present in both db and dbx, the binary is forbidden.

Architecture

In the Reference Software Stack, UEFI Secure Boot relies on the support of the authenticated variables via the Trusted Services SMM Gateway SP and the RSE Protected Storage service. See Secure Services for more information.

During the system build stage, the following 4 authenticated variable files are deployed in the booting partition:

• PK.auth

• KEK.auth

• db.auth

• dbx.auth

Those authenticated variable files are derived from sample UEFI Secure Boot keys.

Note

These authenticated variable files used in RD-Aspen are used only for test purposes, they must not be used for production.

Fig. 28 UEFI Secure Boot

The diagram shows the UEFI Secure Boot process in the Reference Software Stack. On the first boot only, authenticated variables are enrolled and provisioned as follows:

1. U-Boot loads the authenticated variables from the boot partition.

2. U-Boot calls SMM Gateway SP for the SMM Variable Service.

3. SMM Gateway calls SE-Proxy SP.

4. SE-Proxy SP calls RSE’s Protected Storage service via MHUv3. The service is used to store the authenticated variables.

Subsequently, and on all subsequent boots, the process is as follows:

1. U-Boot loads the signed systemd-boot image from the boot partition and verifies it.

2. systemd-boot boots Linux using U-Boot runtime services. The signed Linux kernel image is verified by U-Boot.

Note

In some manual test steps in the Arm Automotive Solutions demo build section, the firmware flash images need to be recreated with the following command:

kas shell -c “bitbake firmware-fvp-rd-aspen -C deploy”

This will clear all the data in the RSE Protected Storage including the enrolled authenticated variables. The authenticated variable files in the boot partition are not deleted after the first boot, so they can be enrolled again in the next boot.

This is only for the convenience of demonstrating the Reference Software Stack. In a production environment, the authenticated variable files must be removed for the sake of security.

Please see Chapter Secure Boot and Driver Signing of the UEFI Specification to learn more about UEFI Secure Boot.