Port the SBSFU to STM32F730 in XiP mode

[JYeh.9]

Hi,

I just went over the X-Cube-SBSFU material and tried to compile the example projects to get an overall picture of this function.

The MCU I used is STM32F730I8 and I am using the STM32F7308-DISCO board.

As only 64kB flash is available in STM32F730 series, the external memory execution(XiP) is needed in my application.

I would like to understand the feasibility to port the SBSFU package to a F7 MCU when running in XiP mode.

The example package did provide the example for STM32F769I, but it only uses the internal flash.

My rough idea is to put the SECoreBin and SBSFU in the internal flash and the slot 0 and 1 user app in the external NOR flash.

Could anyone help to validate the feasibility?

Thanks,

Jay

[Jocelyn RICARD]

Hello Jay,

yes this is exactly what needs to be done.

The secure boot code should be kept in internal flash to take advantage of the internal protections for the keys.

Slot 0 and Slot1 will be in external flash. This means you will not have the same level of firmware content protection compared to internal flash.

Best regards

Jocelyn

[JYeh.9]

Hi Jocelyn,

Thanks a lot for your reply.

I have two more questions:

1. As the user app also references the SE interface. If the user app is put in the external flash, could it still have access the SE interface API put in the internal flash?
2. Could the external NOR flash in the XiP mode still be written by the STM32 API?

Regards,

Jay

[Jocelyn RICARD]

Hello Jay,

1. Yes, you will keep same behaviour as base STM32F769 Disco. The fact to have 2 different memory areas does not change anything in the CPU execution capabilities.
2. This point is something I missed. If you have only one external flash, you will not be able to update this flash while executing code in the same flash. You need to deativate the XIP and change mode to be able to write.

So, in the 2 slots setup, you will have to find a way to write the new firmware in the SLOT1 without executing code in SLOT0. Solutions are either using RAM or part of the 64KB of internal flash. Depending on the way you download the new firmware, it could be tricky.

Other solution is to have a second external flash on FMC but with cost increase.

Best regards

Jocelyn

[JYeh.9]

Hi Jocelyn,

Thanks a lot for the information.

As the external flash could not be written in the XiP mode, I might just implement the SBSFU single image method to put the firmware download logic and flash writing code in the internal flash. If firmware upgrade is needed, a NVIC_SystemReset is fired to jump from user app to the secure bootloader and then execute the firmware upgrade.

By the way, as the user app firmware binary is decrypted after installation, to put the firmware in external flash would lower the security level.

As there's AES accelerator in STM32F730, do you know if it is possible to do bus decryption in Xip mode?

To be more detail, the firmware binary stays encrypted in external flash, and the AES accelerator decrypts the read data on the fly for CPU to execute.

Thanks a lot,

Jay

[Jocelyn RICARD · Accepted solution]

Hi Jay,

Yes, single image update is possible. You just need to implement a mechanism that tells the secure boot to switch to firmware update. This will use the local loader to download the new firmware and then install it in a secure way. In the SBSFU example, you can to this by pressing the user button while resetting.

Regarding your second question, you would need a dedicated HW that would do On The Fly DECoding (OTFDEC). This is not available on STM32F7 family.

Today, only STM32L5 implements this feature. OTFDEC will be available on next generation of high performance STM32.

A workaround would be to encrypt a part of your firmware. After launching, this part would be decrypted in RAM, to be executed from this RAM location.

You would need to implement this decryption mechanism in the secure engine, and provide a service to your application. The secure engine is designed to add easily new services accessible from application.

Best regards

Jocelyn

[JYeh.9]

Hi Jocelyn,

Thanks a lot for your comprehensive explanation and information.

Now I have enough info to proceed to implementation.

Regards,

Jay

[JYeh.9]

Hi,

One more additional question:

Is is possible to have the external flash area stay encrypted and after the system reset, the SBSFU decrypts the code in external flash and load the user app code to an external SRAM and then execute in SRAM?

In this way, the external flash would stays encrypted, but an external SRAM would be needed.

Lots of modification might be needed, but I would like to know if it is feasible.

Thanks.

[Jocelyn RICARD]

Hi Jay,

I don't see any blocking issue using this mechanism.

The startup time will raise significantly.

And as you say, this require the development of a specific loader to decrypt and copy application code in RAM.

I would suggest introducing the encrypted fw hash in the header, so that before decrypting the fw in RAM you check that firmware was not corrupted. Then you decrypt in RAM and check the decrypted fw hash as it is already done. This would prevent launching the decryption on corrupted firmware.

Best regards

Jocelyn