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

 

 

 

[felixlee]

Hi, Is there any documentation for getting started with stmwb55 mcuboot?

[Jocelyn RICARD]

Hello @felixlee ,

the STM32WB55 is supported by the X-CUBE-SBSFU. We don't have any example using mcuboot for this chip.

Best regards

Jocelyn

[ReneAlexandeR]

Hello! 

I am in the same situation as OP, I want to create a bootloader for my board based on the STM32H750 series microcontroller. We have the QSPI flash to run the code from and a SPI flash where we will initially download the image, as a staging area. We have been looking into SBSFU but then we came across this information about SBSFU where it says that "there is no longer evolutions on the SBSFU legacy" (Security:SBSFU legacy - stm32mcu). 

I would like to know what solution would you recommend, as we are at the start of a new project and we want to ensure that we are future-proof. What does the roadmap look like for these products? Which ones will be actively maintained? 

Thank you in advance. 

Best regards,

Rene 

[Jocelyn RICARD]

Hello @ReneAlexandeR ,

the article is a bit misleading maybe. It says there will be no evolution but it does not say it will not be maintained.

No evolution means X-CUBE-SBSFU will not include new features but when an important issue is detected it will be fixed in next  release. So, X-CUBE-SBSFU is still maintained. This is the only solution provided for legacy products.

Best regards

Jocelyn