Boot process

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

  • SI0 RAMFW image

RSE uses the Application Processor secure flash for:

  • Application Processor BL2 (AP BL2) image

Layout of generated images

rse-otp-image.img, rse-rom-image.img, rse-flash-image.img and ap-flash-image.img are raw, partition-less image blobs. *.wic is a partitioned image containing 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:


Layout of the generated images

Trust chain

To make the platform secure, it is critical to protect each booting component from the execution of malicious code. This is implemented by building a trust chain where each step in the execution chain authenticates the next step before execution. The authentication of the images is done with hash (SHA-256) and digital signature (RSA-3072) validation.

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 (RSE RT, SI Cl0 RAMFW) and AP Secure flash (AP BL2).

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 NVM 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 NVM 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 image is stored without encryption, so it is only authenticated. The 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 lookup 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

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.


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:

    • 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

    • 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

    • Jumps to RSE Runtime in the RSE SRAM

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

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

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. systemd-boot loads and boots the Linux kernel from the boot partition.

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 development ROTPK, which is used only for the development purposes. Hash of ROTPK is embedded in AP BL2 image.

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.

Introduction

The Reference Software Stack implements UEFI Secure Boot as a method of verification 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

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


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 Reproducing the use cases 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.