Increasing the flash partition for the Secure Firmware in TF-M for MPS2-AN521 board emulated using Qemu
Problem: ARoT app is too large, that the image build fails.
Error: /home/gramshan/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: bin/tfm_s.axf section `.ER_UNPRIV_CODE' will not fit in region `FLASH' /home/gramshan/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: region `FLASH' overflowed by 114956 bytes Memory region Used Size Region Size %age Used FLASH: 572684 B 447 KB 125.11% RAM: 54556 B 1 MB 5.20%
To overcome this issue, I changed the flash_layout header file (https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/platfor...) such that the secure side size is (FLASH_S_PARTITION_SIZE) 700+KB from the 512KB default for the MPS2 AN521 app, and correspondingly update the non-secure side FLASH_NS_PARTITION_SIZEto be 300KB. This builds the tfm_merged.hex file, But fails it to boot the app.
So, I do not use your ARoT, but just built as non-secure app - the 'hello_world' Zephyr app that prints a one line hello_world on the console, but using the modified partition layout. This too fails to boot, in that the "hello world" is not printed. I debugged this to find that it is BL2 that is failing.
I see that the Panic occurs during the image swapping operation, this is because the image to be filled in the primary slot is identified as invalid and the secure boot stops. The TF-M thinks some firmware upgrade is happening, the integrity check fails and panics, thus inducing a Fault Injection Hardening defense.
Now I am stuck with this issue and I do not know how to proceed further, any help on how to change the flash partition sizes in a clean manner would be appreciated.
Hi Gowri,
The secure image seems increased very much compared to the default TF-M build. Is new secure partition added in the build? May I know the TF-M version and build command you used? I build tf-m of version(325ec1af) with " -DTFM_PLATFORM=arm/mps2/an521 -DTEST_NS=ON -DTEST_S=ON " command after updating FLASH_S_PARTITION_SIZE to 0xAF000 and FLASH_NS_PARTITION_SIZE to 0x4B000. It works well.
By the way, is the image loaded at the primary slot correctly or loaded at the secondary slot? If it is loaded at primary slot and there is no image in the secondary slot, no swap should happen.
Regards, Sherry Zhang
-----Original Message----- From: Gowri Ramshankar via TF-M tf-m@lists.trustedfirmware.org Sent: Monday, October 23, 2023 7:50 AM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Increasing the flash partition for the Secure Firmware in TF-M for MPS2-AN521 board emulated using Qemu
Problem: ARoT app is too large, that the image build fails.
Error: /home/gramshan/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: bin/tfm_s.axf section `.ER_UNPRIV_CODE' will not fit in region `FLASH' /home/gramshan/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: region `FLASH' overflowed by 114956 bytes Memory region Used Size Region Size %age Used FLASH: 572684 B 447 KB 125.11% RAM: 54556 B 1 MB 5.20%
To overcome this issue, I changed the flash_layout header file (https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/platfor...) such that the secure side size is (FLASH_S_PARTITION_SIZE) 700+KB from the 512KB default for the MPS2 AN521 app, and correspondingly update the non-secure side FLASH_NS_PARTITION_SIZEto be 300KB. This builds the tfm_merged.hex file, But fails it to boot the app.
So, I do not use your ARoT, but just built as non-secure app - the 'hello_world' Zephyr app that prints a one line hello_world on the console, but using the modified partition layout. This too fails to boot, in that the "hello world" is not printed. I debugged this to find that it is BL2 that is failing.
I see that the Panic occurs during the image swapping operation, this is because the image to be filled in the primary slot is identified as invalid and the secure boot stops. The TF-M thinks some firmware upgrade is happening, the integrity check fails and panics, thus inducing a Fault Injection Hardening defense.
Now I am stuck with this issue and I do not know how to proceed further, any help on how to change the flash partition sizes in a clean manner would be appreciated. -- TF-M mailing list -- tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org
Hi Sherry,
Thanks for your response! Gowri and I are working together, so will respond to save time.
- The runtime env we have is emulation using QEMU, not a physical MPS2 FPGA board. I do not yet see if & how it should make a difference, given that with equal partition sizes of NS an S, there is no issue, Anything you can think of that might counter this reasoning?
- QEMU does not have the same exact runtime setup as the MPS2 FPGA board has. There are no slots as you describe.
- With the same partition sizes you have mentioned, I to see the same problem, that the "hello world" of the non-secure Zephyr sample "hello_world" app does not print anything as expected. Tracing it down, points to the BL2 issue that Gowri described in her message.
- We are initiating the build using Zephyr 'v.3.4.0' build env. The TF-M hash for this branch is "79a6115d3".
Aside from the above: did you have to change anything in the TF-M build cmake or other files to accommodate the partition size changes?
Regards, -Arun.
Hi Arun,
My reply is in the colored below.
Regards,
Sherry Zhang
-----Original Message----- From: Arun D via TF-M tf-m@lists.trustedfirmware.org Sent: Monday, October 23, 2023 8:03 PM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: Increasing the flash partition for the Secure Firmware in TF-M for MPS2-AN521 board emulated using Qemu
Hi Sherry,
Thanks for your response! Gowri and I are working together, so will respond to save time.
- The runtime env we have is emulation using QEMU, not a physical MPS2 FPGA board. I do not yet see if & how it should make a difference, given that with equal partition sizes of NS an S, there is no issue, Anything you can think of that might counter this reasoning?
[SZ]: I used the mps2/an521 fvp model instead of the FPGA board. But I see no board difference issue that can cause this issue.
- QEMU does not have the same exact runtime setup as the MPS2 FPGA board has. There are no slots as you describe.
[SZ]: Which bootloader is used in your code? Is it MCUboot? MCUboot has two slots for each image: one primary slot and one secondary slot. It is actually a fixed storage area.
- With the same partition sizes you have mentioned, I to see the same problem, that the "hello world" of the non-secure Zephyr sample "hello_world" app does not print anything as expected. Tracing it down, points to the BL2 issue that Gowri described in her message.
[SZ]: As a mentioned in the last email, no image upgrade should occur if there is only one image which locates in the primary slot in MCUboot.
- We are initiating the build using Zephyr 'v.3.4.0' build env. The TF-M hash for this branch is "79a6115d3".
[SZ]: You are using https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/ repo? Seems this commit hash is not found in this repository.
[cid:image001.png@01DA0666.EA227AD0]
Aside from the above: did you have to change anything in the TF-M build cmake or other files to accommodate the partition size changes?
[SZ]: My build environment is the default one in TF-M repo above with RTX running on the nonsecure as the os. I only changed the values of these two macros. No other change is made.
Regards,
-Arun.
--
TF-M mailing list -- tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.orgmailto:tf-m-leave@lists.trustedfirmware.org
Hi Sherry,
Thanks for your response.
We are able to build TF-M from the TF-M repos (Github and Linaro hosted), and execute the images on QEMU. Changing the partition sizes in this build env seems work as you see. It seems the area for us here to investigate is how Zephyr OS (https://github.com/zephyrproject-rtos/zephyr) build env differs from the native TF-M. Zephyr Git env does import TF-M sources, perhaps from Github repo (not Linaro, which you may be using).
Regards, -Arun.
Hello.
We identified the issue in our configuration. We had not adjusted the Zephyr's DTS file for the board (zephyrproject/zephyr/boards/arm/mps2_an521/mps2_an521_ns.dts). Specifically, the path to "/reserved-memory/code: memory@100000" had to be changed such that it is code: memory@12F000 { reg = <0x0012F000 DT_SIZE_K(300)>; };
from the original: code: memory@100000 { reg = <0x00100000 DT_SIZE_K(512)>; };
Hope this helps anyone else encountering this.
tf-m@lists.trustedfirmware.org
-
Arun D -
Gowri Ramshankar -
Sherry Zhang