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]
3.1. Update client[edit source]
As Update client, OpenSTLinux rely on default update client such as RAUC.
It ensures a secure connection to the Client and control the images that are stored in mass storage. 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.
3.2. TF-A BL2 update management[edit source]
The OpenSTLinux uses the standard FWU boot process implemented in TF-A_BL2_overview.
TF-A_BL2_overview first read the metadata partition to determine the bank ID to be booted and its current state. The bank ID will specify the FIP image to be loaded. The 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.
When a trial state is detected, TF-A BL2 set trial counter in backup registers (FWU_INFO) which is decremented after each try. The counter is set to 3 in case of potential issue during the boot process.
The BL2 informs the next boot stages about the bank ID used. This data is used by the Update client to switch the bank to accepted when the boot has been completed. It uses the backup register FWU_INFO to share the bank ID used. It will be up to the Update client to accept the bank and change the bank to regular mode.
3.3. Metadata generation script[edit source]
Version used in oepnstlinux
Fields
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 