MCUboot Validation Failure Due to Incorrect Image Signing Process
The core issue revolves around the failure of MCUboot to validate a signed binary image in a multi-image configuration when using Trusted Firmware-M (TF-M) on an ARM Cortex-M33-based STM32L552ZE-Q microcontroller. The error message indicates that the image in the primary slot is not valid, and MCUboot is unable to find a bootable image. This problem arises despite using the default RSA-3072 key provided by MCUboot for signing the TF-M binary (tfm_s.bin). The issue is further complicated by the presence of the MCUBOOT_MEASURED_BOOT flag in the TF-M configuration, which introduces additional requirements for the image signing process.
The error message during boot highlights a mismatch between the expected and actual image validation process. The key components involved in this issue are:
- MCUboot: A secure bootloader for microcontrollers that validates signed firmware images before execution.
- TF-M (Trusted Firmware-M): A reference implementation of secure processing environment firmware for ARM Cortex-M processors.
- ImgTool: A utility used to sign firmware images for MCUboot.
- RSA-3072 Key: The default cryptographic key used for signing and validating images.
The root cause of the issue lies in the interaction between the MCUBOOT_MEASURED_BOOT flag and the image signing process. When MCUBOOT_MEASURED_BOOT is enabled, TF-M expects additional metadata in the signed image, which is not included by default in the ImgTool command. This results in a validation failure during the boot process.
Missing Boot Record Metadata in Signed Image Due to MCUBOOT_MEASURED_BOOT Flag
The primary cause of the MCUboot validation failure is the absence of the --boot-record option in the ImgTool command when signing the TF-M binary. The MCUBOOT_MEASURED_BOOT flag, which is enabled by default in TF-M, requires the inclusion of a boot record in the signed image metadata. This boot record contains measured boot data, which is used for attestation and secure boot validation.
The MCUBOOT_MEASURED_BOOT feature is designed to enhance security by providing a mechanism to measure and record the state of the boot process. This measurement is used to ensure that the system has booted securely and that the firmware has not been tampered with. However, this feature introduces additional complexity in the image signing process, as the signed image must include the necessary metadata to support measured boot.
The ImgTool command used in the initial signing process does not include the --boot-record option, which results in a signed image that lacks the required metadata for measured boot. Consequently, MCUboot fails to validate the image, as it cannot find the expected boot record in the image metadata.
Another potential cause of the issue is a mismatch between the key used for signing the image and the key used by MCUboot for validation. However, in this case, the same RSA-3072 key is used for both signing and validation, so this is unlikely to be the root cause. The issue is instead related to the missing boot record metadata.
Correcting the Image Signing Process with Boot Record Metadata
To resolve the MCUboot validation failure, the image signing process must be updated to include the --boot-record option in the ImgTool command. This option ensures that the signed image contains the necessary metadata for measured boot, allowing MCUboot to validate the image successfully.
The corrected ImgTool command should be as follows:
python imgtool.py sign -k ./trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 8 -v 1.3.0 -H 0x400 --pad-header -S 0x2D000 --pad --boot-record ./trusted-firmware-m/cmake_build_gcc_fix/bin/tfm_s.bin ./trusted-firmware-m/cmake_build_gcc_fix/bin/tfm_s_signed.bin
The --boot-record option instructs ImgTool to include the measured boot metadata in the signed image. This metadata is essential for MCUboot to validate the image when the MCUBOOT_MEASURED_BOOT flag is enabled.
In addition to correcting the ImgTool command, it is important to ensure that the TF-M configuration is consistent with the image signing process. The MCUBOOT_MEASURED_BOOT flag should remain enabled in the TF-M configuration, as it provides enhanced security for the boot process. However, developers should be aware of the additional requirements introduced by this flag and ensure that the image signing process is updated accordingly.
To further troubleshoot and validate the image signing process, the following steps can be taken:
- Verify the TF-M Configuration: Ensure that the
MCUBOOT_MEASURED_BOOTflag is enabled in the TF-M configuration. This flag is typically set in the TF-M build configuration files (config.cmakeor similar). - Check the ImgTool Version: Ensure that the version of ImgTool being used supports the
--boot-recordoption. The version used in this case (1.7.2) should be compatible, but it is always good practice to verify compatibility with the TF-M and MCUboot versions being used. - Validate the Signed Image: After signing the image with the corrected ImgTool command, verify that the signed image contains the expected metadata. This can be done using tools such as
arm-none-eabi-objdumporxxdto inspect the binary file. - Test the Boot Process: Flash the signed image to the target board and test the boot process. MCUboot should now be able to validate the image and proceed with the boot process.
By following these steps and ensuring that the image signing process includes the necessary metadata for measured boot, the MCUboot validation failure can be resolved. This ensures that the system boots securely and that the firmware is validated correctly.
Conclusion
The issue of MCUboot validation failure in a multi-image configuration with TF-M and ARM Cortex-M33 is primarily caused by the absence of the --boot-record option in the ImgTool command when signing the firmware image. The MCUBOOT_MEASURED_BOOT flag, enabled by default in TF-M, requires this additional metadata for secure boot validation. By updating the ImgTool command to include the --boot-record option and ensuring consistency between the TF-M configuration and the image signing process, the issue can be resolved. This ensures that the firmware image is correctly signed and validated by MCUboot, allowing the system to boot securely.
