1. Article Purpose[edit | edit source]
The purpose of this article is to explain the mechanism implemented in the OpenSTLinux ecosystem. It relies on the ARM Platform Security Firmware Update for the A-profile Arm[1] specification.
2. Firmware update overview[edit | edit source]
The secure firmware update mechanism controls and ensures the integrity and authenticity of new firmware installed. The purpose of the secure firmware update (FWU) is to outline the communication process between an update client and a secure bootloader. The firmware stores the key of the secure firmware update and records all the mandatory parameters to control the FWU state. The FWU concept is also compatible with the UEFI UpdateCapsule mechanism.
OpenSTLinux implements the FWU feature, where the update client also serves as the update agent and directly manages the firmware storage from the non-secure side.
2.1. Firmware update store mechanism[edit | edit source]
The firmware update depends on a set of parameters that define the current update state and provide information about the images to be loaded. The firmware update store contains:
- Firmware images.
- Metadata saved in dedicated partitions.
To provide a firmware store, dedicated areas need to be reserved in the boot device.
- N areas (banks) are reserved to store N images.
- Two areas are reserved for metadata storage (with the same metadata duplicated in both areas).
2.1.1. Firmware images[edit | edit source]
Firmware images are organized in banks.
There must be a minimum of two banks, each representing a collection of images that need to be updated simultaneously.
This bank is the main entity of update mechanism that changes during an update. During the boot process, the bootloader uses the bank ID described in the metadata.
2.1.2. Metadata[edit | edit source]
The metadata[1] is the description of the different banks that are listed in the firmware store for a particular bank list.
The metadata is composed of:
- The number of firmware banks
- A description of a list of firmware images composing the bank and their associated location
- The ID and the state of the bank described in the metadata
The firmware store references the images entries using UUID. The UUID is used to find the associated partition in the boot storage. UUID is commonly used in GPT table to identify the partitions.
A set of firmware images in a bank is designed to be compatible with the boot process. Thanks to this mechanism, commonly known as A/B mechanism, it is possible to switch between each bank while keeping the previous partition safe.
The bootloader first reads the metadata to detect the bank ID to be used and also to control the state of the bank. Metadata is a collection of non-secure parameters, but it requires an integrity check, which is saved in the metadata using a CRC value. In case of error detection, a second metadata partition must be defined.
2.2. Firmware update state machine[edit | edit source]
Firmware update follows a defined state of a bank ID during the process. A bank update follows the state machine illustrated in the figure below:
- The regular state is the state where all images of a bank ID have been accepted.
- The staging state is a transition state when the update client is updating firmware images in a bank.
- The trial state is the state when the firmware update store has been fully updated (firmware images and associated metadata) but has not yet been accepted. This state is mandatory as it allows testing new images and rolling back to the previous regular bank in case of an error. The trial stage also allows bypassing the update anti-rollback counter.
The state of a bank is managed by the update agent. It is in charge of switching the metadata parameters when the update process is requested and completing the process. The bootloader only reads the metadata and returns the bank ID used through a platform specific mechanism.
3. OpenSTLinux implementation[edit | edit source]
OpenSTLinux offers a secure firmware update feature thanks to TF-A BL2 bootloader, which manages the firmware update. The ecosystem release ≥ v5.1.0 implements the metadata version 2.
3.1. TF-A BL2 update management[edit | edit source]
The OpenSTLinux uses the standard FWU boot process implemented in TF-A BL2 bootloader.
TF-A BL2 first reads the metadata partition to determine the bank ID containing the FIP to be loaded and its current state.
The OpenSTLinux flash layout defines two entries for FIP (FIP-A and FIP-B). The FIP contains a complete set of consistent images (firmware and certificates) that allow the platform to boot.
The TF-A BL2 exchanges the bank ID with the next stages using a secure backup register:
- STM32MP13x lines
: Firmware update register - STM32MP15x lines : Firmware update register
- STM32MP25x lines : Firmware update register
This data is used by the update client to switch the bank to accepted (or refused) when the boot has been completed.
This register stores the bank ID used to boot the FIP and also contains a trial counter. When a trial state is detected, TF-A BL2 sets the trial counter in the backup register which is decremented after each try. The counter is default set to 3 in case of potential issue during the boot process. It can be updated by modifying the FWU_MAX_TRIAL_REBOOT in plat/st/common/stm32mp_common.c .
It is strongly recommended to enable the watchdog in TF-A BL2 in case of error crash linked to incorrect images.
3.2. Metadata generation tool[edit | edit source]
U-Boot offers a way to generate the initial metadata required for the first boot. This tool is called mkfwumdata. It is compiled when enabling the following option:
CONFIG_TOOLS_MKFWUMDATA=y
To have information about the tool options, you can run the following command from the U-Boot source directory:
man doc/mkfwumdata.1
Or, directly with the tool:
mkfwumdata help
Here is the command used by default on STMicroelectronics boards:
mkfwumdata -g -v 2 -i 1 -b 2 8a7a84a0-8387-40f6-ab41-a8b9a5a60d23,19d5df83-11b0-457b-be2c-7559c13142a5,4fd84c93-54ef-463f-a7ef-ae25ff887087,09c54952-d5bf-45af-acee-335303766fb3 metadata.bin
3.3. Update client[edit | edit source]
The update client ensures a secure connection to the remote server and controls the images stored in the firmware store.
The metadata must be also updated to ensure the complete update process.
It sets the bank update from regular to staging during the update process.
Once done, the update client must set the bank to trial state (also in the backup metadata).
After rebooting the system, the client must check the bank ID used to accept or refuse the last updated.
4. References[edit | edit source]
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 