1. Article Purpose[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 source]
The secure firmware update mechanism allows to control and ensure the integrity and authenticity of new firmware installed. The concept of the secure firmware update (FWU) is to specify the exchange between a Update client and a Secure bootloader. The firmware store is the key of the secure firmware update as it records all the mandatory parameters to control the FWU state. The FWU concept also suits the UEFI UpdateCapsule mechanism.
OpenSTLinux implements the FWU feature where the Update client is also the Update agent and directly manages the firmware store from non secure side.
2.1. Firmware update store mechanism[edit source]
The firmware update relies on a set of parameters that define a the current update state and information about the images to be loaded. The firmware update store contains :
- Firmware images.
- Metadata partitions save in a dedicated partitions.
To provide a firmware store, some dedicated area need to be reserved in the boot device.
- N areas (banks) to store N images.
- 2 areas store some metadata (The same metadata is duplicated).
2.1.1. Firmware images[edit source]
The firmware images are organized in banks.
It must exist a minimum of 2 banks and each of them represents a collections of images that need to be updated at the same time.
This bank is the default entity of update mechanism that is changed during an update. During the boot process, the bootloader will use the bank ID described in the metadata.
2.1.2. Metadata[edit source]
The metadata 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 that composed the bank and the 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 image in a bank is designed to be compatible to complete the boot process. Thanks to this mechanism, commonly name A/B mechanism, it is possible to switch between each banks keeping safe the previous partition.
The bootloader first read the metadata to detect the bank ID to be used and also control the state of the bank. Metadata is a collection of non secure parameters but it requires a integrity check that is saved in the metadata thanks to a CRC value. In case of error detection, a second metadata partition must be defined.
2.2. Firmware update state machine[edit source]
Firmware update follows a defined a state of a bank ID during the process. A bank update follows the below state machine:
- The regular state is the state where all images of a bank ID has 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 is not yet accepted. This state is mandatory has it allows to test the new images and rollback to the previous regular bank in case of error. The trial stage allows to bypass 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 to complete the process. The bootloader only read the metadata and return the bank ID used through a platform specific mechanism.
3. OpenSTLinux implementation[edit source]
OpenSTLinux offers the secure firmware update feature thanks to TF-A BL2 bootloader that manages the firmware update. The ecosystem release ≥ v5.1.0 
implements the metadata version 2.
3.1. TF-A BL2 update management[edit source]
The OpenSTLinux uses the standard FWU boot process implemented in TF-A BL2 bootloader.
TF-A BL2 first read the metadata partition to determine the bank ID containing the FIP to be loaded and its current state.
The OpenSTLinux flashlayout defined 2 entries for FIP (FIP-A and FIP-B). The FIP contains a complete set of consistent images (firmware and certificate) that allow to boot the platform.
The TF-A BL2 exchanges with the next stages the bank ID thanks to 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 also is used to store the bank ID used to boot the FIP and also contains a trial counter. When a trial state is detected, TF-A BL2 set 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 script[edit source]
TF-A BL2 offers a way to generate the initial metadata that are required for the first boot. The metadata are defined in a json file and generated at build time thanks to a python script : tools/fwu_gen_metadata/fwumd_tool.py .
The default metadata is located in the common platform folder : plat/st/common/default_metadata.json
This default metadata file is built during the default build process. It defines:
- A default FIP GUID to reference the image type to be loaded.
- Two default partition GUID that must be used in the layout as it refers to GPT table entries for block devices storage or offset in case of raw devices. Offset are defined in the plat/st/common/include/stm32mp_io_storage.h .
3.3. Update client[edit source]
The update client ensures a secure connection to the remote server and control the images that are 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 (in the backup metadata too).
After rebooting the system, the client must check the bank ID used to accept or refuse the last updated.
4. References[edit source]
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 