The secure firmware update implemented in STM32MP family follows the ARM proposal Platform Security Firmware Update for the A-profile Arm[1]
1. Firmware update overview[edit | edit source]
Secure update firmware purpose is to be able to update the boot loader. TF-A itself is not updated by this process, only the FIP (optee, uboot, and their respective signatures and certificates).
This is a secure update because wrong images (due to error while download, flash, or tamper) won't boot, but system is still runable, it will boot the last known working FIP after N (system defined) attempts.
To provide a secure update some area need to be reserved in the boot device.
- 2 area store some metadata (The same metadata is duplicated)
- N (2 in Openstlinux) area to store N FIP.
The metadata and one backup register drive the boot process to select the FIP we want to boot.
1.1. Figures[edit | edit source]
The next figure explains how the update process download a new FIP.
Next figure explains how the boot occurs, taking into account the secure firmware update.
2. Metadata[edit | edit source]
The metadata describes the status of a firmware update process. It define wheres to find all FIP, and stores the status of an update process:
- regular: points to a FIP which is known working. The BL2 will load and run this FIP.
- trial: a new fip has been downloaded, but is not yet accepted. The metatadata also stores the last known working fip. The BL2 will load and run the new FIP, but if the BL2 (thanks to FWU_INFO TAMP backup register) detects the boot already fails 3 times, it will load and run the last accepted FIP.
2.1. Metadata internal[edit | edit source]
Metadata structure is defined in include/drivers/fwu/fwu_metadata.h Note that Metadata are only read by the TF-A, only the Update Client will write/update them.
Important fields for TFA in metadata are:
metadata->active_index metadata->previous_active_index
These fields define the index of img_prop[] currently active and the previous working index.
TF-A will load, verify, then boot software of the FIP found at the active_index.
metadata->img_entry[0] metadata->img_entry[0].img_type_uuid metadata->img_entry[0].location_uuid
We only have one img_entry, has we only need to find one FIP (define by the haredcodec FIP UUID in img_type_uuid) from one filesystem (the boot device UUID define in location_uuid
metadata->img_entry[0].img_prop[X] metadata->img_entry[0].img_prop[X].img_uuid metadata->img_entry[0].img_prop[X].accepted
X (X can ben 0 to 1 in OpenSTLinux (deinfined by NR_OF_FW_BANK)
img_uuid define where to find the image X, directly with the UUID with a GPT partitioned device (EMMC or SD-CARD) or thanks to a correspondance between the UUID and an offset in case of RAW-NAND and NOR boot device)
accepted is set to 1 by the Update Client after a full boot success on this image.
3. TF-A[edit | edit source]
Firmware update is enabled with PSA_FWU_SUPPORT=1 in makefile. TF-A will manage FIP selection (to boot the expected FIP), and will manage recovery and error management after a new FIP has been downloaded from non secure world.
As soon as the Secure Boot Update specific code has selected a FIP to boot, the boot continue as a non updatable one. TF-A will secure the boot, it checks each element in FIP are correctly signed, decipher if needed, manage anti-rollback, and if all is fine, run them.
3.1. Firmware update boot process[edit | edit source]
On boot TF-A reads values from metadata: metadata->active_index, metadata->previous_active_index, metadata->img_entry[0].img_prop[metadata->active_index].accepted.
3.1.1. After a FIP update[edit | edit source]
After a FIP update the active_index is not yet accepted (we have metadata->img_entry[0].img_prop[metadata->active_index].accepted == 0) we are in Trial mode.
To avoid infinite boot loop with a non working FIP, as long as we are in Trial mode, before selecting FIP, we decrement the trial counter (a Backup Register). If the trial counter is not 0, we load, authenticate, run the active_index FIP, (after a succefull boot in this configuration, the Update Agent has to update the accepted field to 1). If the trial counter is 0, we know the boot didn't go till the Update Agent in all previous attempt, this 4th time, the TF-A will load, authenticate, and run the the FIP at previous_active_index (a FIP image that was known working). This is the responsability of the Update Agent to detect that the over the air update failed, and take actions (retry download, ...). Indeed the Update Agent can read the metatadata, and knows, thanks to a Backup Register, which index value was used to select the FIP.
3.1.2. Regular start[edit | edit source]
In regular case, the active_index FIP is known working (accepted value is 1). We load, verify, run entries from the selected FIP, and will set the Backup Register that store the number trial boot to FWU_MAX_TRIAL_REBOOT[2] (default value: 3) to prepare any future trial mode.
4. Update Client[edit | edit source]
The Update Client responsibility is to manage the FIP update. It runs as a deamon on linux.
- check if a new FIP image is availlable
- download the new image
- program the new FIP in correct place.
- manage metadata:
- set new value for
active_indexandprevious_active_indexandacceptedafter flashing a new FIP. - set
metadata->img_entry[0].img_prop[boot_index].acceptedto 1, if it detects that the boot_index saved in backup register is not yet accepted. - manage the case a newly flashed FIP failed (when the backup register storing firware update information value is
metadata->previous_active_index).
- set new value for
- ↑ [ Architecture 1.0BET0" AFWU-PSA-A_DEN0118_1.0BET0.pdf
- ↑ plat/st/stm32mp1/stm32mp1_def.h
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.