STiROT_OEMuROT example results in hard fault

[jens-vdb]

Dear community,

I have been experimenting with secure boot on the STM32H573I-DK using the latest git checkout of STM32CubeH5 (see https://github.com/STMicroelectronics/STM32CubeH5).

The STiROT and OEMiROT examples run fine out-of-the-box. However, when I try to provision and run the STiROT_OEMuROT example, then the board seems to be in a boot loop. When I insert a "while (1) {};" line after https://github.com/STMicroelectronics/STM32CubeH5/blob/main/Projects/STM32H573I-DK/Applications/ROT/OEMiROT_Appli_TrustZone/Secure/Src/main.c#L135 , the boot loop stops. So it seems to be a hard fault when the jump to non secure code is made.

Note that I am using the code as it is checked in with Git: no changes were made to the example code.

Can anyone help me in debugging this code? I have already followed the tutorial on https://wiki.st.com/stm32mcu/wiki/Security:How_to_start_with_STiRoT_OEMuRoT_on_STM32H573 multiple times, line by line.

Best,

Jens

[CMYL]

Hi @jens-vdb 

Can you check if you correctly set the path of STM32CubeProgrammer and that the selected application path is correct in env.bat script ?

According to the Wiki, in which step the issue is seen ?

Best regards

 

 

 

 

[jens-vdb]

Hi,

I have verified the correctness of the path of STM32CubeProgrammer. To confirm that, I set it to a non-existent path and then the provisioning script failed. For what it's worth, I'm using Linux. So instead of the *.bat files, I'm using the *.sh files.

The tutorial on https://wiki.st.com/stm32mcu/wiki/Security:How_to_start_with_STiRoT_OEMuRoT_on_STM32H573 fails in step 4. The crash happens after the line "[INF] Jumping to the first image slot" is printed, then the board resets. The following output can be seen on the serial console:

[INF] TAMPER Activated
[INF] Flash operation: Op=0x0, Area=0x0, Address=0x0
[INF] Starting bootloader
[INF] Swap type: none
[INF] verify counter 0 1000000 1000000
[INF] counter 0 : ok
[INF] verify sig key id 0
[INF] checking public key 48 5b
[INF] verifying signature hlen 20
[INF] signature OK
[INF] Swap type: none
[INF] verify counter 1 1000000 1000000
[INF] counter 1 : ok
[INF] verify sig key id 1
[INF] checking public key 46 5b
[INF] verifying signature hlen 20
[INF] signature OK
[INF] Swap type: none
[INF] verify counter 2 1000000 1000000
[INF] counter 2 : ok
[INF] verify sig key id 2
[INF] checking public key 46 5b
[INF] verifying signature hlen 20
[INF] signature OK
[INF] Swap type: none
[INF] verify counter 3 1000000 1000000
[INF] counter 3 : ok
[INF] verify sig key id 3
[INF] checking public key 46 5b
[INF] verifying signature hlen 20
[INF] signature OK
[INF] verify counter 0 1000000 1000000
[INF] counter 0 : ok
[INF] hash ref OK
[INF] verify counter 1 1000000 1000000
[INF] counter 1 : ok
[INF] hash ref OK
[INF] verify counter 2 1000000 1000000
[INF] counter 2 : ok
[INF] hash ref OK
[INF] verify counter 3 1000000 1000000
[INF] counter 3 : ok
[INF] hash ref OK
[INF] Bootloader chainload address offset: 0x1a000
[INF] Jumping to the first image slot
[INF] TAMPER Activated
[INF] Flash operation: Op=0x0, Area=0x0, Address=0x0
(...)

I can break that reset cycle by changing the code as described in my original post. If I put the while(1){}-loop from my original post at the beginning of the HardFault handler function in https://github.com/STMicroelectronics/STM32CubeH5/blob/main/Projects/STM32H573I-DK/Applications/ROT/OEMiROT_Appli_TrustZone/Secure/Src/stm32h5xx_it.c#L57, I am able to break the reset loop (thus confirming that the reset loop is triggered by a hard fault), and I can do some fault analysis according to the Cortex-M33 manual at https://www.st.com/resource/en/programming_manual/pm0264-stm32-cortexm33-mcus-programming-manual-stmicroelectronics.pdf :

1. authorize debugging (dbg_auth.sh) with "Level 3 Intrusive Debug";
2. connect to the device using the STM32CubeProgrammer;
3. read out the CFSR register: UFSR=0, BFSR=0x92 (BFARVALID, STKERR, PRECISERR), MMFSR=0;
4. read out the BFAR register: BFAR=0x2009FFFC.

From the linker script of the non-secure application, BFAR indicates the highest word on the stack (0x20050000-0x200A0000). So it looks like the non-secure application cannot access its own stack for some reason.

 

Note that the STiROT example code works out of the box with the default application selected (env.sh: stirot_boot_path_project=Applications/ROT/STiROT_Appli). But the STiROT example does *not* work anymore If I configure it to use the TrustZone application instead:

• select the STiROT_Appli_TrustZone in env.sh: stirot_boot_path_project=Applications/ROT/STiROT_Appli_TrustZone
• modify the STiROT_Config.xml to set the firmware the be "not full secure": Is the firmware full secure=0x00 (according to https://www.st.com/resource/en/application_note/an6007-getting-started-with-stirot-st-immutable-root-of-trust-for-stm32h5-mcus-stmicroelectronics.pdf)

No output is provided on the serial console, and discovery of the provisioned device indicates that only STiROT init and config are done (ST HDPL1 status):

discovery: target ID.......................:0x484
discovery: SoC ID..........................:0x5b003f 0x3332510a 0x35353537 0x0
discovery: SDA version.....................:2.4.0
discovery: Vendor ID.......................:STMicroelectronics
discovery: PSA lifecycle...................:ST_LIFECYCLE_IROT_PROVISIONED
discovery: PSA auth version................:1.0
discovery: ST HDPL1 status.................:0x3
discovery: ST HDPL2 status.................:0xffffffff
discovery: ST HDPL3 status.................:0xffffffff
discovery: Token Formats...................:0x200
discovery: Certificate Formats.............:0x201
discovery: cryptosystems...................:Ecdsa-P256 SHA256
discovery: ST provisioning integrity status:0xeaeaeaea

 No idea if this STiROT exmaple information is on-topic, but I thought it might be relevant.

[jens-vdb]

Extending on the seemingly inaccessible stack address, could it be that the call to unsecure_sram3 does not behave as expected (if I understand the code correctly, then that function should "unsecure" the memory to be used by the nonsecure application)? I don't really understand why that call is needed anyways, because the SAU does not configure SRAM3 (0x20000000->...) to be secure.