Will app based on CubeMX v6.11.1 (BSP1.28.0) FreeRTOS with MPU disabled work with STM32 Secure Boot

[Torben1]

Hi,

I'm looking into introducing STM32 Secure Boot and Secure Firmware Update based on X-CUBE-SBSFU library on my project with app based on CubeMX v6.11.1 (BSP1.28.0).

I noted in CubeMX the MPU option is still not available for FreeRTOS - which is used by my application.

It looks like the Secure Boot will be using MPU, but the app won't - will this become a showstopper for Secure Boot?

Thanks,

Torben

[Bubbles · Accepted solution]

Hi @Torben1,

you didn't mention for which STM32 MCU is the application intended. They are not equal in security features.

The secure boot, once finished, is then inactive. In most cases your application is free to reconfigure the MPU as necessary. Especially on H7, G4 or G0 the HDP or securable memory area hides the SB code and the MPU has no obligation to protect it.

So you can change or disable the MPU configuration without compromising the SB in any way.

BR,

J

[Torben1]

Hey @Bubbles,

I'm using STM32F429BI6 MCU using CubeMX v6.11.1 to configure FreeRTOS.

Using this toolset and MCU, the FreeRTOS configuration disables MPU.

I understand the MPU being disabled when running the FreeRTOS image will not affect Secure Boot functionality.

In this context, I suppose the question is answered, so thank you.

Out of curiosity, do you know what the reason behind disabling MPU for FreeRTOS is?

Br

Torben

[Bubbles]

Hi @Torben1,

my expertise is more on SBSFU side than the FreeRTOS. I'm not sure but it's probably the goal of the FreeRTOS developers to start the code with clean sheet and remove any possible annoyances in advance.

I don't think it really needs to be disabled completely. MPU is not only matter of security, setting memory regions as cacheable or bufferable also affects performance and stability.

BR,

J

[Bubbles]

PS, the STM32F4 series are not the security champion of the STM32 ecosystem. See for example AN5156 for comparison with other series. If the SBSFU uses PCROP, it's fine, but if the code you chose does not use it, write protection is the only protection of the boot code when the MPU is disabled.