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]

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

[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.

[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