STM32U5 SBSFU external flash questions

[rjh]

Hi,

We are using an STM32U585 with the application running from external flash, on an octospi bus. We are also using external SRAM. The external memory architecture on our board is heavily influenced by the B-U585I-IOT02A design (same ports, slightly different parts used).

We have successfully experimented with the SBSFU solution here and we have a couple of questions:

1. Is there a flow diagram anywhere that clearly shows the boot sequence for this example/solution? We understand this is difficult because of all the configuration options, but we are still trying to understand if the application images are authenticated on every boot, or only when being copied to the primary slot by the bootloader and how exactly the MCUBOOT_USE_HASH_REF functionality plays into this.
2. We do not need a secure app. Is it possible to remove this and have the bootloader run the non-secure app directly? Any pointers on how to achieve this? This is not a major issue, but it would make the memory map a bit simpler, and presumably would slightly improve boot times.
3. Are there any examples of using this SBSFU solution with external flash? From a web search I see there is evidence of examples from X-CUBE-SBSFU that do use external flash (e.g. here, albeit possibly not for the STM32U5 family) but is there anything more up-to-date available? We would like to use OTFDEC for the image(s) in external flash but is this likely to cause problems?
   1. If not, can you give any pointers about how to go about this? Where do we need to focus and what do we need to be concerned about? We currently have a simple (non secure) bootloader in place to boot from external flash, so should we set this as a second stage bootloader (after the secure bootloader from SBSFU)?
   2. We don't yet fully understand the MPU and memory protection (WRP) options on this part. Can they be used with external flash and RAM. Anything we need to consider here?
4. We have a lot of external flash available (to spare), so plenty of room for a primary slot, and two secondary slots per image (for firmware updates). Are we correct in thinking that mcuboot only supports two slots per image and overwrite or swap (using the intermediate swap flash partition) are the only possibilities?
   1. Also not a big deal, but as we want a fallback option (if the new image fails to successfully boot/connect to the cloud) using an overwrite scheme for update, with two backup/update slots, seems like it would improve performance (during the update process).

Thanks,

RJH

[Bubbles]

Hi @rjh ,

I may not be able to answer all the questions, but here is my contribution:

1) The SBSFU is based on the Arm TF-M solution, so whatever you cannot find in the ST documentation will most probably be described in Arm TF-M documentation. The image integrity is checked by default on boot, in function bootutil_img_validate(). The MCUBOOT_USE_HASH_REF offers accelerated boot thanks to image SHA256 reference management. Image verification mainly consists of verifying the SHA256 of the image (integrity check) and then verifying the signature of this SHA256 (authentication check). If successful, the SHA256 is stored as a reference for the next boot. At the next boot, the signature verification is skipped if the SHA256 of the image matches the reference stored.

2) Yes, it's possible.

3) The problem with OTFDEC is that it only offers decryption acceleration. You'd have to manage the encryption yourself, or leave the external memory image in plain. The MCU can't set any protections on external memory besides MPU, which only applies to the CPU based access, doesn't for example apply to DMA access.

4) The external memory is generally well suited for storage of encrypted backup images. I suggest looking here mcuboot | Secure boot for 32-bit Microcontrollers!

BR,

J

[rjh]

Hi @Bubbles,

Thanks for your reply.

1) That makes sense to me now! I have been drowning in documentation over the last couple of days, and so while I think I understood this at one point it got driven out of my brain again. I was thinking that the step of generating the sha256 hash of the image was being skipped, which obviously wouldn't make any sense. Skipping the signature check in this scenario does make sense.

2) I guess this is my next step so. If nothing else it should allow me get more familiar with how everything works.

3) Understood re. OTFDEC only offering decryption. I'm not on the team that is creating our end-product application, but I'm told it's already approx. 5MB, and expected to grow to approx. 8MB, so it obviously won't fit in internal flash. 

We'll worry about getting the rest of the secure boot, and secure firmware update, functionality working first before diving into using OTFDEC for the application primary slot (I'm pretty sure our security review dept. will insist on it). 

Presumably the encryption will only need to be performed when the bootloader is swapping the image into the primary slot, so this should be doable, right? 

As only the bootloader itself will be living in internal flash we will have plenty of space available for any non-volatile data/settings that may need to be updated more regularly.

One confusion I do have is that AN5447 lists "Encrypted image execution in external Flash memory" as a top-level feature for the TF-M based SBSFU solution:

I'm not seeing evidence of this, at least not in the STM32U5 example. Am I missing something, or is this table just saying this is possible (but the actual implementation is an exercise for the reader)?

Thanks,

RJH