- Last edited 6 months ago ago
Secure Firmware Update
The secure firmware update implemented in STM32MP family follows the ARM proposal Platform Security Firmware Update for the A-profile Arm
1 Firmware update overview
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.
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.
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
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:
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 metadata->img_entry.img_type_uuid metadata->img_entry.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
metadata->img_entry.img_prop[X] metadata->img_entry.img_prop[X].img_uuid metadata->img_entry.img_prop[X].accepted
X (X can ben 0 to 1 in OpenSTLinux (deinfined by
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.
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
On boot TF-A reads values from metadata:
3.1.1 After a FIP update
After a FIP update the
active_index is not yet
accepted (we have
metadata->img_entry.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
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 (default value: 3) to prepare any future trial mode.
4 Update Client
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
acceptedafter flashing a new FIP.
metadata->img_entry.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
- set new value for