Clarification Needed: SBSFU Legacy, MCUBoot, and STiRoT

[alireza-mal]

Hi everyone,

We’ve been using the XCUBE-SBSFU bootloader in our industrial-grade project and recently noticed that SBSFU is now labeled as a legacy bootloader. It seems the new recommended bootloader is based on MCUBoot. Additionally, I’ve come across information on STiRoT, which implements a root of trust similar to what SBSFU legacy already offers.

This has left us with a few questions, and we’d greatly appreciate any clarification:

1. Why has SBSFU been marked as legacy and replaced? Were there specific limitations or issues with SBSFU that led to this change?
2. How do we transition to MCUBoot? The MCUBoot website mentions it doesn’t currently support STM32 controllers, and the ST wiki says support is “coming soon.”
3. What role does STiRoT play? It seems similar to SBSFU legacy but is relatively new. Is it a better option? Should we consider switching to it, and if so, why?

Any insights or guidance would be greatly appreciated.

Thanks.
@Jocelyn RICARD I’ve noticed your valuable input on SBSFU-related topics and would be grateful if you could share your thoughts on this.

[Jocelyn RICARD]

Hello @alireza-mal ,

thank you for your question as this is not obvious indeed.

The X-CUBE-SBSFU is covering many STM32 devices using ARM Cortex-M0+, Cortex-M4 and Cortex-M7 . It was developed internally at beginning targeting STM32L4 with its firewall capability. This is why SBSFU implemented this Secure Engine that isolates crypto operations and keys from the rest of the Secure boot code.

On devices not implementing this firewall, this secure engine is protected using MPU. Secure engine runs in privileged mode while SBSFU runs in unprivileged mode.

Then came STM32 based on ARM Cortex-M33. This new Cortex brings TrustZone mechanism for isolation together with ARM PSA initiative. ARM PSA provides a comprehensive framework for IoT security, and TF-M implements this framework on Cortex-M processors by offering secure boot, secure partitioning of secure services, and IPC mechanisms for internal communication.

ST decided to address this framework and to port the solution on the Cortex-M33 based STM32. STM32L5 at that time.

The TF-M uses mcuboot as secure boot solution (also called bl2 in the framework).

An important effort was done to make this mcuboot porting robust to be able to address PSA Level 3 and SESIP Level 3 certifications.

This is why, SBSFU solution on STM32 based on Cortex-M33 are using this mcuboot based solution. STM32L5, STM32U5, STM32WBA.

Now, with recent introduction of STM32H5 based on Cortex-M33, we have now a secure boot already provided in system flash. For this solution, the dev team also used mcuboot based solution that was simplified and made robust to attacks to be able to be certified. This STM32CubeH5 also propose a secure boot solution as code example that can be adapted to your needs. So, these different solutions need to have different names.

This is why you have now :

STiRoT : ST immutable Root of Trust: Secure boot solution provided in secure system flash. This is a ROM bootloader.

OEMiRoT : OEM immutable Root of Trust: Secure boot solution based on mcuboot provided as code example that can be adapted to your needs

STuRoT: ST updatable Root of Trust: provided only in context of Secure Manager on STM32H5

OEMuRoT: OEM updatable Root of Trust: Second stage bootloader (Requires either STiRoT or OEMiRoT as first stage). This solutions allows having an updatable secure boot to address complex use cases.

This move to mcuboot based solution initiated on the Cortex-M33 based devices is now also addressing new devices like STM32C0, STM32U0, STM32H7RS and coming ones.

I hope this clarifies

Best regards

Jocelyn