Memory limitations using SBSFU

[EBonv]

Hello,

I am developing a SBSFU for a custom application on a NUCLEO-H753ZI board. The application works well on its own. However, when I switch its linker script for the one of the example UserApp delivered with the SBSFU archive, I encounter some unexpected behavior.

Namely, the code still works, and I am actually able to correctly encrypt it and download it on the board. However, it does not work for large inputs. Specifically, my code was initially able to deal with inputs as large as at least 21k bytes. But with the new memory configuration, it only works for inputs up to 13k bytes. Any input larger than that causes what seems to be a segmentation fault on the board.

I believe the problem is that my application does not have enough memory anymore since the SBSFU split the memory in several parts. I should also mention that my application carries heavy cryptographic operations, therefore my assumption seems to make sense.

I tried to increase the sizes of various areas in the linker files, in particular the ones that seemed related to the RAM of the user application but with no success.

My question is then: is there any way I can increase the size of the memory allocated to the execution of my application in the SBSFU setting?

Thank you in advance for any suggestion.

[Jocelyn RICARD]

Hello,

The SBSFU does not "consume" any RAM on the STM32H7.

In the example provided, the RAM used by the Secure Engine (4KB) is retrieved from the application but this is not necessary.

So, you can use the full RAM for your application.

Besides I would advise having a look to the Reference manual to see all RAM you can access:

0x20000000 DTCM : 128KB

0x24000000 AXI SRAM : 512 KB

0x30000000 SRAM1 : 128KB

0x30020000 SRAM2 : 128KB

And SRAM3, SRAM4 ... So, you should have more than enough RAM for your application :)

The point is that by default only DTCM RAM is used but you can use much more!

Best regards

Jocelyn

[EBonv]

Hello @Jocelyn RICARD​ , thank you for your answer.

Since I posted this question, I realized the problem was that my original application was using the AXI SRAM to store the initialized data section (.data in linker files) while the UserApp which linker file I copied is using the DTCM RAM as you mentioned which is much smaller.

My question then becomes: how do I use more RAM? I tried to modify the linker files in order to move the initialized data section of the SBSFU into AXI SRAM. However, doing so broke something in the SBSFU: it compiles correctly, sets up the protections as expected (RDP, PCROP, etc) but then crashes after power cycling it.

The exact issue I have now (unsolved yet) and the steps I followed are described here: https://community.st.com/s/question/0D53W00000ttFFsSAM/nucleoh753zi-sbsfu-how-to-move-application-ram-location-in-memory

If you can have a look at the post linked above, that would greatly help me as I don't understand what my modifications broke in the SBSFU.

Best regards,

Etienne

[Bubbles]

Hello @EBonv​ ,

sorry for stalling the previous thread.

Anyway I bet the problems you experience stem from the MPU settings.

It's extremely difficult to tune all protections at once after modifying the linker settings. I suggest to try disabling all protections besides MPU (in app_sfu.h) and try tracing the execution like that. It should help you pinpoint the exact root cause. Then you can gradually return other protections and see if they also need some changes.

Unfortunately I'm starting my vacation tomorrow and I won't be able to help you more for next 2 weeks.

J.

[Jocelyn RICARD]

Hello Etienne,

I would recommend not changing the SBSFU mapping if not needed.

The application's RAM mapping is completely independent from SBSFU's RAM mapping.

So, keep your application's RAM mapping as it when it works on its own.

Best regards

Jocelyn

[EBonv]

Hello Jocelyn, thank you for your answer.

I am not sure about the independence of the application's RAM and the one from the SBSFU. For example, I found that modifying the mapping in the example UserApp such that:

_estack = 0x24080000;
 
MEMORY
{
 ISR_VECTOR (rx)   : ORIGIN = __ICFEDIT_intvec_start__, LENGTH = VECTOR_SIZE
 APPLI_region_ROM  : ORIGIN = APPLI_region_ROM_start, LENGTH = APPLI_region_ROM_length
 APPLI_region_RAM  : ORIGIN = 0x24000000, LENGTH = 512K
}

is enough to break it. The only modification I brought is that the RAM of the application should now be located in the 0x24000000 memory area. Here by "break it", I mean the following behavior:

• The application is recognized as authentic by the SBSFU
• The application is not run as expected, it is reset by a watchdog reset every 6 seconds.

The exact output in the terminal emulator is the following (repeating every 6s):

======================================================================
=              (C) COPYRIGHT 2017 STMicroelectronics                 =
=                                                                    =
=              Secure Boot and Secure Firmware Update                =
======================================================================
 
 
= [SBOOT] SECURE ENGINE INITIALIZATION SUCCESSFUL
= [SBOOT] STATE: CHECK STATUS ON RESET
          WARNING: A Reboot has been triggered by a Watchdog reset!
          INFO: Last execution detected error was: Watchdog error.
= [EXCPT] WATCHDOG RESET FAULT!
= [SBOOT] STATE: CHECK NEW FIRMWARE TO DOWNLOAD
= [SBOOT] STATE: CHECK USER FW STATUS
          A FW is detected in the slot SLOT_ACTIVE_1
= [SBOOT] STATE: VERIFY USER FW SIGNATURE
= [SBOOT] STATE: EXECUTE USER FIRMWARE

Then I think more modifications are needed in order make the SBSFU compatible with an application using the RAM in another area than the DTCM RAM. Or am I missing something?

Best regards,

Etienne

[Jocelyn RICARD · Accepted solution]

Hello Etienne,

well you actually found an interesting issue and made me mad at some point :)

Debugging was **** ** this one!

Issue is related to the activation of the MMU though the flag located in app_sfu.h

This flag enable MMU but also ICache and DCache (in main() of SBSFU)

The issue is that this cache is not disabled before jumping in the application where you re-enable the cache.

This leads to completely weird issue where some addresses values read from RAM are actually read from cache.

This results in hard fault ... and explains why you had a watchdog reset.

So, in order to solve the issue you need to deactivate the cache in SBSFU before jumping in application.

This can be done in SFU_SecUserActivationInRam function inside #if defined(SFU_MPU_PROTECT_ENABLE)

Just add 2 lines:

  SCB_DisableDCache();

  SCB_DisableICache();

I'm not 100% sure this is the best solution but at least is works on my side.

I will raise this point internally.

Best regards

Jocelyn

[EBonv]

Hello Jocelyn,

Thank you very much for looking into it (at the price of some of you sanity). I doubt I would have been able to spot such an issue by myself.

I applied your modifications and, as promised, it is enough to solve my problem :) . Don't hesitate to let me know if a better fix is found in the future.

Best regards,

Etienne

[Piranha]

For a bootloader also consider not turning cache memories on at all. First, cache memories enable or significantly increase the ability of performing timing attacks for software cryptographic algorithm implementations. Second, the code without cache management is simpler and avoids not only potential software bugs, but also some cache related hardware bugs in Cortex-M7 core.