cancel
Showing results for 
Search instead for 
Did you mean: 

SBSFU/TFM debugging on M33 (U5) with TrustZone

bear2023R
Associate III

Hello,

after being busy with some other stuff, we are finally back to face problems with secure bootloader integration.

What we learned so far (our learnt points could be wrong and corrections would  be greatly appreciated):

  1. ST provides a very nice CubeMX-based ecosystem, which is, however, totally incompatible with ST's either SBSFU or TFM examples: there are different folder structures, different initializers, no clear integration between the three whatsaver.
  2. Debugging either TFM or SBSFU is complex and time-consuming task: every time you make even single statement changed in your code, you have to pass through complete process of: 
    1. Recompiling all three (four in case of local loader) projects: customer non-secure, TFM secure, and BOOTloader itself, with signing etc.
    2. Upload all three to the FLASH by using relevant scripts and CubeProgrammer.
    3. Starting with bootloader and only then use some breakpoints in custom non-secure code. SW/HW resets, watchdogs etc. further complicate the process.
    4. If the project contains some other stuff in FLASH, like TouchGFX assets, all things complicate even more.
    5. Because of (2), it is close to impossible to do quick recompiles to test some hooks to external hardware or, let's say, on-screen appearance of some assets on specific LCDs (simulator doesn't always help because of different gamuts etc.)

      An obvious answer to this problem would be a "switchable" code, that fully runs without any bootloader part at all, so the bootloader gets attached only at some final, close to delivery stage.
      HOwever, we failed to achieve it so far and limping somewhere in the midway because:
      1. TFM seems cannot be used without bootloader and its own core at all. So if anyone wants to use any TFM secure services, he/she is obliged to deal with all the above "beauty" of  TFM debugging.
      2. SBSFU seems to be way more promising in terms of separating bootloader and user code, even though lacking some security stuff like TFM's secure storage. However, even SBSFU example we failed to isolate so far and after loading at bootloader's defined FLASH location it refuses either switch to non-secure mode, or to see some RAM and FLASH areas after SAU initialization, or ..., or .... So, obviously we are still missing some steps, which are described either nowhere or their descriptions spread over a multitude of different documents, datasheets, workshops and this forum articles. Even examples in FW packages are created by different ST teams with noticeable differences between initializers, start-up files, and some other stuff. Which doesn't help to make a sense out of it and requires really long learning curve.

So the final questions would be like this:

  1. Is there any clear path, described within a single document, which defines a clear step-by-step sequence of integrating the existing CubeMX-based TrustZone-enabled application (U5 if it matters) with secure bootloader in the way, that the latter not required to be a part of compilation/debugging process until really needed? SBSFU-like will do. TFM will be obviously even better, but we really doubt about this possibility and not hoping for that too much.

  2. If there is no such information (or just in addition to one if it is, or even instead of it):
    would it be possible to obtain from ST a modified example "...STM32Cube_FW_U5_V1.7.0\Projects\B-U585I-IOT02A\Applications\SBSFU" that may run with and without necessity to compile, pre-load and debug everything from "SBSFU_Boot" project? Just fully exclude it from such an alternative "non-boot-loader" configuration but retaining all the security initializers and service inside of...Projects\B-U585I-IOT02A\Applications\SBSFU\SBSFU_Appli\Secure\  project?

Many thanks in advance!

 

0 REPLIES 0