Skip to content

Conversation

nandojve
Copy link
Member

The trusted-firmware-m requires specific instructions when signing the images to allow local development and FOTA. This PR extends the sign process inside Zephyr to generate the hex files with the confirmed image to load firmware for development and production purposes. It add the missing binary sign to generate the correct non confirmed image to allow FOTA upgrade. These images now respect the TF-M/FWU state machine FOTA is now possible.

These was tested on STM32U5A5xx SoC with custom OTP and Keys.

Fixes #94204

@zephyrbot zephyrbot added the area: TF-M ARM Trusted Firmware-M (TF-M) label Aug 13, 2025
@nandojve nandojve added this to the v4.3.0 milestone Aug 13, 2025
@tomi-font tomi-font requested a review from frkv August 14, 2025 11:00
@arnebdr
Copy link
Contributor

arnebdr commented Aug 14, 2025

I have tested the patch, works for my project using U585. I think its a good solution

@nandojve nandojve requested a review from nordicjm August 14, 2025 17:05
@nandojve nandojve force-pushed the tfm/fix_sign_images branch from a108a23 to 343a5d0 Compare August 15, 2025 08:41
@nandojve
Copy link
Member Author

nandojve commented Aug 15, 2025

  • patch set tries to address the CI failings
  • rebase

I could validate that west build -p -b mps2/an521/cpu0/ns samples/tfm_integration/tfm_ipc -t run

Generating files from /home/gfbudke/zephyr/mainline/zephyr/build/zephyr/zephyr.elf for board: mps2
image.py: sign the payload
image.py: sign the payload
image.py: sign the payload
image.py: sign the payload
[245/246] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: cortex-m33
char device redirected to /dev/pts/1 (label hostS0)
qemu-system-arm: warning: nic lan9118.0 has no peer
[INF] Starting bootloader
[INF] Beginning BL2 provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[INF] PSA Crypto init done, sig_type: EC-P256, using builtin keys
[INF] Image index: 1, Swap type: none
[INF] Image index: 0, Swap type: none
[INF] Bootloader chainload address offset: 0x80000
[INF] Image version: v0.0.0
[INF] Jumping to the first image slot
Booting TF-M v2.2.0+g021e2bbd5
[INF] Beginning TF-M provisioning
[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE
[WRN] This device was provisioned with dummy keys. This device is NOT SECURE
[Sec Thread] Secure image initializing!
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][PS] Encryption alg: 0x5500200
[INF][Crypto] Provision entropy seed...
[INF][Crypto] Provision entropy seed... complete.
*** Booting Zephyr OS build v4.2.0-1753-g00228f4ca10a ***
TF-M IPC on mps2
The version of the PSA Framework API is 257.
The PSA Crypto service minor version is 1.
Generating 256 bytes of random data:
6B C9 9D 2C 60 0B 0D 82 83 61 C2 5B 2D C7 BB 98 
EE F5 4E 9B 8E A7 38 46 9A BE C0 1B 18 51 43 1A 
60 F6 83 02 EF 33 8C 22 F9 92 B1 99 57 A0 EE 59 
B5 5F 2D 47 15 5E AE 52 DA E7 4A 87 49 AC C8 95 
F2 AB 44 18 F9 3B DE E6 2B B4 95 E3 8E 7B D7 DF 
C8 B5 C8 B4 0E 28 4E 90 DA 53 36 2A 16 C2 A6 A6 
24 29 0D 1F EA FC 28 2E 5B AF BC 9D 60 14 92 C8 
20 8D B5 03 5D 01 14 1F FC 80 7A 46 04 F5 64 42 
00 02 5B FE 12 55 FB 3B BA A4 7A 23 ED EC B9 02 
74 B1 5A 3F 8F 62 F6 F3 C8 C3 14 22 A0 A8 96 BC 
B1 B1 C0 AB A1 D3 F6 96 9E 23 8C 4B AE 19 FB B3 
8C 70 85 87 DC B7 43 78 1D 13 FD 7C 1B F9 C0 FF 
98 D3 E6 83 AB EF 3F A9 EB 5D CE D9 CD FC EF 68 
64 CC C1 EB 57 67 72 76 8B C6 57 CE 6B E0 03 D5 
5E 76 95 8B F8 0F 91 0C B8 C2 54 62 D2 59 A1 8B 
1E DE 79 E6 C7 04 4A A2 7D 10 74 16 B0 16 58 E9 

@nandojve nandojve force-pushed the tfm/fix_sign_images branch from 343a5d0 to 00228f4 Compare August 15, 2025 13:46
@nandojve
Copy link
Member Author

  • patch set tries to address the CI failings
  • rebase

Copy link
Contributor

@wearyzen wearyzen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't looked at the PR but just adding a -1 so that the MPS2/MPS3 changes don't get merged. I'll have a look at this next week once I am done with my current high priority task.

BTW, @nandojve, currently mps4/**/fvp/ns boards are not enabled because TF-M doesn't generate few required hex files, would this PR help with that? if you would like to try you can add below 1 line here

default "arm/mps4/corstone320/fvp"   if BOARD_MPS4_CORSTONE320_FVP_NS

@nandojve
Copy link
Member Author

Hi @wearyzen ,

Are you maintaining the ARM platform ?

I haven't looked at the PR but just adding a -1 so that the MPS2/MPS3 changes don't get merged. I'll have a look at this next week once I am done with my current high priority task.

I have a product that require TF-M + FWU ASAP in mainline. This changes was already proved that makes FWU work by community inclusive. I'm only trying to fix mps2/3 because are in CI but I'm fine to exclude then from tests because those bring 0 value at moment, if they build.

BTW, @nandojve, currently mps4/**/fvp/ns boards are not enabled because TF-M doesn't generate few required hex files, would this PR help with that? if you would like to try you can add below 1 line here

default "arm/mps4/corstone320/fvp"   if BOARD_MPS4_CORSTONE320_FVP_NS

I'm not sure because flash layout from ARM does not provide correct info at all. The layout comment says single image but CONFIG_TFM_MCUBOOT_IMAGE_NUMBER=2.

https://discord.com/channels/1106321706588577904/1106321982900945017/1405922987491983581

@wearyzen
Copy link
Contributor

Hi @wearyzen ,

Are you maintaining the ARM platform ?

Yes I am.

I haven't looked at the PR but just adding a -1 so that the MPS2/MPS3 changes don't get merged. I'll have a look at this next week once I am done with my current high priority task.

I have a product that require TF-M + FWU ASAP in mainline. This changes was already proved that makes FWU work by community inclusive. I'm only trying to fix mps2/3 because are in CI but I'm fine to exclude then from tests because those bring 0 value at moment, if they build.

That would be breaking the mps2/mps3 ns boards isn't it? if you could you change the code to have the current behavior for mps2/mps3/mps4 and the new change only for others then I don't have any issue but with current PR, I will still need some time to understand the changes to approve it.

BTW, @nandojve, currently mps4/**/fvp/ns boards are not enabled because TF-M doesn't generate few required hex files, would this PR help with that? if you would like to try you can add below 1 line here

default "arm/mps4/corstone320/fvp"   if BOARD_MPS4_CORSTONE320_FVP_NS

I'm not sure because flash layout from ARM does not provide correct info at all. The layout comment says single image but CONFIG_TFM_MCUBOOT_IMAGE_NUMBER=2.

https://discord.com/channels/1106321706588577904/1106321982900945017/1405922987491983581
its fine, as long as adding the line I mentioned above to enable corstone320/fvp ns doesn't break the build it is fine for now.

This excludes the mps3/corstone300/an547/ns from psa tests becuase
QEMU does not model the QSPI flash in MPS3 boards as real QSPI flash,
but only as simple ROM, so attempting to rewrite the flash from the
guest will fail. See more details in:

zephyrproject-rtos#94470 (comment)

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
The mps3/foo/ns define flash layouts in tf-m to allow
CONFIG_TFM_MCUBOOT_IMAGE_NUMBER be 1 or 2. In the Zephyr project when
building the samples the value selected is 2.

The layout changes are necessary to allow use the --max-sectors options
when signing the images. It ensures that flash layout is respected. To
allow this the compatible "soc-nv-flash" was added in the reserved
memory and the fixed-partitions were defined.

In addition, the ISRAM was redefined to expose the correct size and
values for both S and NS firmware. This makes clear to user how the
momory was selected.

For example, see general details in:
https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git/%2B/refs/heads/main/platform/ext/target/arm/mps3/corstone310/common/partition/region_defs.h#116
https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git/%2B/refs/heads/main/platform/ext/target/arm/mps3/corstone310/common/config.cmake#13

Note:
 - Not all mps3 ISRAM have the same size and design should take that in
   consideration.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
The external partitions are defined dependent from S and NS images. This
move the external partitions from common to the S image. The NS image
will be defined in future to allow correct usage of MCUboot.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
The parritions from the stm32l562e_dk/stm32l562xx/ns board is not align
with tf-m. This fixes the partition alignment.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
The current version of TF-M script that sign MCUboot image uses a
default alignment of 1. This value varies between flash devices
and not all accept the default 1. This improve the script picking
the write-block-size property from the current flash controller
and pass as the --align parameter when signing an image.

Note: This solution works out-of-box for the vast majority of
devices in the Zephyr tree and an exception will throw when
a device is not supported.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
The --max-sectors will helps to catch problems with flash overlap when
merging images. If there is a missalignment from flash partitions
usually the merge process will fail. This pick information from zephyr
flash partitions and flash controller to automatically determine the
max sectors value and apply it when singing an image.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
The current behaviour when signing an image is to set always --pad and
--pad-header for all images unless TFM_USE_NS_APP is set. This does not
allow easy creation of a signed image for FOTA applications. Rewrite
the PAD parameter into HEADER and TRAILER to easy setup more signing
options.

The other important reason to do this change is that NS image when
signed without --pad run in the hardware. However, it do not perform
the MCUboot test image and the FWU never upgrade de image. This will
fix the NS image signing process to correct allow TF-M FWU using the
PSA API functions.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
The current behaviour from signing an image add --pad but do not confirm
the image. This seems to be a mistake because user should inspect in the
Firmware Upgrade software the image status. This means that if an image
is not --confirmed the FSM can not infer correct states. This set the
image as confirmed to fix this issue.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
Make variable that define output files explicity quote HEX in the name.
This is a refactor step to allow introduce BIN files out generation.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
One fundamental use of trusted-firmware-m is to allow IoT applications
to have security and the firmware upgrade FOTA is almost 100% mandatory
in these applications. The current state of files signing process do
not produce the necessary binaries to use with multi image S/NS FWU
once the hex images are not suitable for this use case. This introduces
the missing signed binaries files to be used by FWU partition. The
changes were tested in multi image FWU scenarios and single image can
be easily extended in the future.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
Use cmake_parse_arguments() to be more idiomatic. This make the code
more readable and make it easier to add new options.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
The optional --output-bin parameter instructs the IntexHex class to save
the content as a binary instead intelhex format.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
When CONFIG_TFM_MCUBOOT_IMAGE_NUMBER is 1 the process to create the
final tfm_merged.bin file is more complex. This prepare the content
to introduce the generation of the tfm_merged.bin to be used in FOTA
applications.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
When CONFIG_TFM_MCUBOOT_IMAGE_NUMBER is 1 all the images will be merged.
Currently there is no tfm_merged.bin file to be used in FOTA. This add
the file generation to fulfill that need.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
Add note about BL2 (MCUboot) signing updates when board is build as
TF-M NS.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
This extends the Signing Images details in the build documentation to
highlight the details about confirmed and unconfirmed images in regards
to PSA Certified Firmware Update API.

Signed-off-by: BUDKE Gerson Fernando <[email protected]>
Copy link

@nandojve
Copy link
Member Author

  • CI is green and I think I could address all the topics

Copy link
Contributor

@nordicjm nordicjm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

comment is unrelated anyhow, PR needs a rebase

raise AddressOverlapError("{} has merge issues".format(hex_file_path))

ih.write_hex_file(output)
format = "bin" if output_bin else "hex"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: Build System area: Samples Samples area: TF-M ARM Trusted Firmware-M (TF-M) platform: ARM Arm Limited platform: STM32 ST Micro STM32 Release Notes To be mentioned in the release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TF-M: Image magic is bad for TFM builds with BL2