Inconsistent SBSFU error for Header FW signature verification failure

[jmcoreymv]

I'm starting from the X-CUBE-SBSFU release v2.6.2, using the B-L475E-IOT01A - 2_Images_ExtFlash as a reference.  I've done the minimum porting required to run this on an STM32L4A6 target.

I'm seeing an inconsistent issue where the SBSFU boots up and attempts to verify the Active Slot fw header signature, but fails.  The inconsistency seems tied to the build process, specifically the final step of building the UserApp + postbuild script to generate the combined SBSFU_UserApp.bin.

On a 'good' build, I can flash the SBSFU_UserApp.bin onto the target and it will consistently boot successfully, regardless of the number of re-flash or reboot attempts.

On a 'bad' build, I can flash the SBSFU_UserApp.bin onto the target and it will consistently fail to boot successfully, regardless of the number of re-flash or reboot attempts.

= [SBOOT] SECURE ENGINE INITIALIZATION SUCCESSFUL
= [SBOOT] STATE: CHECK STATUS ON RESET
INFO: A Reboot has been triggered by a Software reset!
= [SBOOT] STATE: CHECK NEW FIRMWARE TO DOWNLOAD
= [SBOOT] STATE: CHECK USER FW STATUS
No resume required : TRAILER_HDR_TEST not valid!
A FW is detected in the slot SLOT_ACTIVE_1
= [SBOOT] STATE: VERIFY USER FW SIGNATURE
= [SBOOT] RuntimeProtections: 0
Header signature verification failure in slot SLOT_ACTIVE_1
Erasing slot SLOT_ACTIVE_1
= [SBOOT] STATE: HANDLE CRITICAL FAILURE
= [SBOOT] STATE: REBOOT STATE MACHINE
========= End of Execution ==========

Again, the only step I'm changing in this process is rebuilding the UserApp + postbuild script.  SBSFU and SECoreBin are not being rebuilt.  It seems to have a ~50% success rate as to whether I'll encounter the error above each time I build/package the UserApp.

When I debugged inside of the SBSFU and SECoreBin, I found the following:

1. SBSFU calls SFU_IMG_VerifyActiveImgMetadata (sfu_boot.c line 1059)
2. Calling CheckAndGetFWHeader (sfu_fwimg_common.c line 709)
3. Calling VerifyHeaderSignature (sfu_fwimg_common.c line 362)
4. Calling SE_VerifyHeaderSignature (sfu_fwimg_common.c line 120)
5. Ultimately reaching SE_SP_SMUGGLE (se_callgate.c line 316), consisting of assembly calls which return SE_ERROR.

The SE_SP_SMUGGLE returning an error is in the same place another issue I have fails as well, I'm guessing they may be related (https://community.st.com/t5/stm32-mcus-security/sbsfu-not-detecting-active-slot-image/td-p/741961)

Thanks

[liaifat85]

The error in SE_SP_SMUGGLE (a function that likely performs secure service calls in assembly) is indicative of an issue within the Secure Engine during the signature verification process.

[jmcoreymv · Accepted solution]

I think this was resolved thanks to this reply on another thread:

https://community.st.com/t5/stm32-mcus-security/sbsfu-not-detecting-active-slot-image/m-p/746176/highlight/true#M7802

In my case, I swapped out the mbedtls to ST_Cryptographic library to resolve this, but the heap increase would likely have fixed the issue as well.