Problems modifying SBSFU to support large application firmware image on dual bank device.

[Arty29]

Hello,

I am adapting the X-CUBE-SBSFU (version 2.5.0) for use in our product which uses the STM32L486RE device and I am using external flash memory to receive the downloaded firmware image. I used the sample project '2_Images_ExtFlash' for the B-L475E-IOT01A board as a starting point and I have been able to get everything up and running on my target hardware. I can bootload a small user application similar to the one used in the sample. However, I have run into some problems because the real application image that I will be installing is larger than a single bank of the MCU internal flash space.

I have configured the bootloader to use one active slot in internal flash and have placed the header of the active image immediately after the SBSFU code (__ICFEDIT_SB_region_ROM_end__). The active image is allocated the remainder of the internal flash with the exception of the last sector that I need to keep reserved for storing application non-volatile data. At this point I have resorted to disabling firewall protection as well as the parts of SFU_IMG_InitImageHandling() that check that the firewall NVData section overlaps the code section, and that the on the firmware headers are under firewall protection.

I understand that for devices with dual-bank flash (such as the STM32L486RE) there are firewall overlap constraints to ensure secrets are protected if the banks are swapped. What is the best way to adapt the SBSFU to work with a large application image size (> single bank)? I would like to provide as much security as possible.

Thank you.

[Jocelyn RICARD]

Hello Arty,

I can see one possibility to achieve your request. This is using the multi slot feature of the SBSFU.

SBSFU is able to define up to 3 independent active slots with associated download slots.

So, you can have a setup with

bank1: SBSFU followed by active SLOT0

bank 2: Firewall protected area followed by active SLOT1

External flash : download SLOT 0 and download SLOT 1

This adds a constraint in your application to split it in 2 slots.

For update, you will need to download the 2 slots independently in external flash and trigger an update of the 2 slots.

I hope this will help

Best regards

Jocelyn

[Arty29]

Hello @Jocelyn RICARD​ , thank you for your suggestion.

I had also been thinking of something along those lines but I'm concerned that it might make maintenance and upgrading of the application firmware more difficult.

Also, the end goal in all this is to provide a means for performing OTA firmware updates on our product. The application will obtain the encrypted firmware image(s) from a URI, copy them into external flash storage and then trigger a software reset. When the SBSFU first runs it should determine that there is new and valid firmware in the download slot(s), install the new image(s) and start the application.

If I were to split the application into two slots is it correct to assume that it would be critical that both download slots be prepared before resetting the device? I'm thinking of a scenario where something went wrong when filling one of the download slots. For example, a corrupted image in one download slot, or after filling one download slot the device loses power or is reset before the second download slot is filled. In that case it is possible that only one slot would be updated and the application would run with different (and potentially incompatible) firmware versions in the two slots.

Thanks again for your help.

[Jocelyn RICARD]

Hello @nonesucheatherland​ ,

In multislot case, you have a master slot that will be updated first. Then if it is will installed (swaped), SBSFU will install other slot if it detects a new firmware is available in associated download slot.

I don't think that there is automatic fallback of first slot if second slot installation fails. Need to check this.

Now, you can use the image validation feature to validate your installation.

So, if you start on slot0 that was well installed but slot 1 failed, you can detect it an trigger a rollback.

I agree this adds complexity.

Other way would be to decrease a little security level and get rid of this firewall specific area in bank2.

This would allow having only one slot in internal flash.

The risk is that if someone succeed in injecting code in your firmware, could write code in RAM, switch banks and read the content of keys. So, the risk is that AES key is leaked allowing attacker to decrypt an update file. But it will not allow installing a forged firmware because public key knowledge does not give ability to sign a new firmware.

If you go this route you would need to make some modification in SBSFU mapping to move this firewall are besides SBSFU.

Best regards

Jocelyn