H7 SBSFU DTCM usage

[David Littell]

Hi All,

Does the SBSFU reserve all of the DTCM in an H7 (stored state information, etc., expected to be stable across Core resets) such that the application shouldn't touch any of it after beginning execution?  The "Protected RAM ..." note in AN5056 Figure 12 implies this, or am I reading it wrong?

Thanks!

[Bubbles]

Hi @David Littell,

let me assume you are referring to the STM32H7B3 SBSFU (there is also one for H750 and some for H753).

The figure 12 is about the STM32L4, but looking at the mapping_sbsfu.icf file I can see that the DTCM is completely reserved by the SE and SB, yes.

But in the map file, most of that memory space is listed as unused. I think you can try reducing this allocation and use some of DTCM for the application. Just make sure to test that modification and also check the MPU settings.

BR,

J

[Bubbles · Accepted solution]

Hi, I checked with the SBSFU developers and they explained the situation. DTCM memory is considered very secure (no DMA access), so the SB is using it a lot. But after boot most of that memory is released for the application to use:

	Size (bytes)	Role (boot time)	Role (run time)
0x20000000 0x20000FFF	4096	Secure Engine's private stack	Secure Engine's private stack
0x20001000 0x200010FF	256	Secure memory activation code area (Reused)	User application RAM (126 960 bytes = 123.98 kB)
0x20001100 0x2001FFEF	126 704	SBSFU RAM (Reused)
0x2001FFF0 0x2001FFFF	16	Shared RAM for Image State Handling	Shared RAM for Image State Handling

Does that answer your question?

BR,

J

[David Littell]

Yes, I believe this does clarify things.  It'd probably be helpful for this kind of information to be include in the AN's.

Thanks,

Dave

[David Littell]

It would've been helpful if those tiny 256- and 16-byte areas ("Secure memory activation code" and "Shared RAM for Image State Handling") had been tucked away at the top of the 4KB Secure Engine's (huge) private stack. That way everything after 0x20001000 would be usable by the application SW.

[SimonK]

I am now looking at the example of the NUCLEO-H753ZI (2_Images_OSC) and the picture looks different.

This is from the manual UM2262:

So actually, not only the stack but also the SE volatile data cannot be touched. Which in the linker file (and MPU configuration) is actually whopping 12KB DTCM RAM that is being protected.

sfu_low_level_security.h

#define SFU_PROTECT_MPU_SRAM_SE_SIZE MPU_REGION_SIZE_16KB
#define SFU_PROTECT_MPU_SRAM_SE_SREG 0xC0U /*!< 16 Kbytes / 8 * 6 ==> 12 Kbytes */

 mapping_sbsfu.ld

/* RAM section */
/* SE RAM1 region protected by firewall */
/* SE stack is placed 1st in RAM, stack overflow does not write on other RAM area */
__ICFEDIT_SE_region_RAM_start__ = 0x20000000;
__ICFEDIT_SE_region_RAM_stack_top__ = 0x20001000;
__ICFEDIT_SE_region_RAM_end__ = 0x20002FFF;
/* Secure memory activation code area - execution in RAM */
__ICFEDIT_SB_HDP_Code_region_RAM_start__ = __ICFEDIT_SE_region_RAM_end__ + 1;
__ICFEDIT_SB_HDP_Code_region_RAM_end__ = __ICFEDIT_SB_HDP_Code_region_RAM_start__ + 0xFF;

Linker script of the example application:

APPLI_region_RAM_start = __ICFEDIT_SE_region_RAM_end__ + 1;
APPLI_region_RAM_length = __ICFEDIT_SB_region_RAM_end__ - APPLI_region_RAM_start + 1;

So as you can see, the application RAM starts after 12KB of SE_region_RAM, and funnily enough, does not include the HDP region?

I am completely lost here on what is going on actually. So much information out there but it's all confusing and insonsistent. User application neither starts at 0x20001100 (as you say), 0x20003100 (as would have made sense here) but 0x20003000 (which does not include the HDP region).

How much of my application memory (and where) do I need to give to the SE?

EDIT: I looked at the non-OSC variant of the code, and it looks different again. Closer to your image above, but still HDP memory is not included and overwritten by application.

EDIT2: Sorry I have to vent somewhere, the SBSFU is close to a catastrophy, I guess there is a reason it is considered legacy now, I imagine its umaintainable at STM's side. I am running this on a Linux PC and there is all kinds of issues. Shell scripts that only start to work, once you convert the windows file endings. Prebuild-scripts that use python3 (good) and postbuild scripts that use python2 (what? why?). It is a total mess :( This needs to run on a CI/CD server, so yeah.

[Jocelyn RICARD]

Hello @SimonK ,

I made a quick test on windows disabling using of prepareimage.exe that is used by default in order to make things easier.

I'm only using Python 3.12.3 and everything is running.

Just in case you need to install some modules. Please check requirements SBSFU\V2.7.0\Middlewares\ST\STM32_Secure_Engine\Utilities\KeysAndImages\readme.txt

Regarding the usage of the RAM used by SBSFU and SE, except if you used the image validation feature, I don't see any reason why you couldn't use it. Only possible protection is the MPU and if MPU is still active when jumping into application (sorry I don't remember of this point), this it is easy to reconfigure it.

The main protection on the STM32H753 is the Secure memory that protects the flash area containing the secure boot. The RAM has not specific protection except MPU.

Best regards

Jocelyn

[SimonK]

See STM32CubeExpansion_SBSFU_V2.7.0/Projects/NUCLEO-H753ZI/Applications/2_Images_OSC/2_Images_SECoreBin/STM32CubeIDE 

prebuild.sh:

  unameOut="$(uname -s)"
  case "${unameOut}" in
    Linux*)     machine=Linux;;
    Darwin*)    machine=Mac;;
    CYGWIN*)    machine=windows;;
    MINGW*)     machine=windows;;
    Windows_NT*)  machine=windows;;
    *)          machine="UNKNOWN:${unameOut}"
    esac
  if [ ${machine} == windows ];then
    cmd=python
  else
    cmd=python3
  fi

vs SECBOOT_ECCDSA_WITH_AES128_CBC_SHA256.sh

uname | grep -i -e windows -e mingw > /dev/null 2>&1

if [ $? -eq 0 ] && [   -e "$prepareimage" ]; then
  echo "prepareimage with windows executable"
  PATH=$basedir"\\win\\prepareimage":$PATH > /dev/null 2>&1
  cmd=""
  prepareimage="prepareimage.exe"
else
  # line for python
  echo "prepareimage with python script"
  prepareimage=$basedir/prepareimage.py
  cmd="python"
fi

 No python3 in the last one. Also, those scripts are very inconsistent in the way they determine what command to run... Btw, it's not an issue of missing python packages. The issue is, that there is no Python2 anymore on current Linux distros (which is a good thing).

---

@Jocelyn RICARD wrote:

Regarding the usage of the RAM used by SBSFU and SE, except if you used the image validation feature, I don't see any reason why you couldn't use it. Only possible protection is the MPU and if MPU is still active when jumping into application (sorry I don't remember of this point), this it is easy to reconfigure it.

---

Use what exactly? See, this is the kind of inconsistent information that you can find everywhere. I really don't know for sure, if my application needs to reserve the first 4KB 4KB+256B or 12KB or 12KB+256B of DTCM RAM. Obviously I can find it out by just testing (or taking a week of time to analyze all the ins and outs of the SBSFU and SE), but that really isn't a preferred way when dealing with secure software, since one mistake could mean the difference between secure and insecure.

[SimonK]

In the mean time, I have found a few more issues...

For example, the MPU is just being disabled and not reset (i.e. the MPU configuration is still loaded internally). Now with the usual way, STM initializes the MPU in all the application examples, this leads to the MPU loading remaining configuration that is in the slots, that are unused/explicitly set by the application.

Also, I have spend multiple hours, trying to find a busfault after enabling the MPU protection in the SBSFU. Turns out, SBSFU disables the ITCM (that is enabled by default) and doesn't enable it again, when launching the user application. All other applications just assume the ITCM is running upon MCU reset (because it's the default). All those applications crash, while initializing the ITCM.

I just activated ENABLE_IMAGE_STATE_HANDLING and it looks like my application is not running anymore, but that will be another tedious debug task for tomorrow.

These are so simple things to fix inside of SBSFU, I wonder why such basic bugs exist. Do people not use ITCM or MPU in their applications? 

[Jocelyn RICARD]

Hello

I'm sorry for late answer.

First regarding your concern.
The goal of SBSFU was to provide a working example for customers wanting to have such feature.
Nowadays secureboot is becoming mandatory in more and more project and such example may not fit all requirements.
The tests were done to make sure the software was robust.
This issues you face are related to the clean setting of the system on application launch.
This is one thing that was underestimated by development team and this is not first time I see such kind of issue.

Now regarding DTCM usage. As I said you can reuse all of it. There is no specific RAM protection on STM32H753
If you enable firmware validation, the firmware image state is stored at end of DTCM:

__ICFEDIT_SB_region_RAM_end__ = 0x2001FFEF;

/* Shared RAM for Image State Handling */
__ICFEDIT_SB_FWIMG_STATE_region_RAM_start__ = __ICFEDIT_SB_region_RAM_end__ + 1;
__ICFEDIT_SB_FWIMG_STATE_region_RAM_end__ = 0x2001FFFF;

So, in such case, you should keep it in your linker file so that secureboot can get the information.

About python version, this is not visible on windows but you are right, this is a mistake.

About MPU reset, this is part of things that are not totally clean when jumping into the application.

About ITCM, again the same kind of issue. Not clean.

I guess these issue were not reported earlier because people fixed them without raising the issue.

Anyway, thank you for sharing your concerns. I will report these points to dev team.

Best regards
Jocelyn