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 proposal 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 User Agent and a Secure boot loader. 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 where the User Agent manages the firmware update 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 is saved in a dedicated partitions and requires an associated backup partition to avoid corruption during update. The firmware update store is also called metadata.
The metadata is composed of :
- a number of firmware banks
- each bank contains a set of firmware images
The firmware store reference 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.
To provide a firmware update store, some dedicated area need to be reserved in the boot device!
- 2 areas store some metadata (The same metadata is duplicated)
- N areas to store N images.
2.2. Firmware update state machine[edit source]
Firmware update follows a defined state machine as defined below:
- 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 User agent 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 udpate anti-rollback counter.
3. OpenSTLinux implementation[edit source]
3.1. User Agent[edit source]
As User agent, OpenSTLinux rely on default update agent 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 agent must set the bank to trial state (in the backup metadata too).
After rebooting the system, the user agent 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 User agent 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 user agent to accept the bank and change the bank to regular mode.
3.3. Metadata generation script[edit source]
Version used in oepnstlinux
Fields
- ↑ [ Architecture 1.0BET0" AFWU-PSA-A_DEN0118_1.0BET0.pdf
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 