SBSFU: A low supply voltage event seems to clear the firmware

MBax.2 · ‎2022-07-22

Hi,

I have a product which runs an application that uses SBSFU on a STM32. The product is battery powered by a small battery. After the small battery is almost depleted, it charges itself by drawing power from a larger external battery. If however that external battery is also empty, eventually the supply of the microcontroller will drop to below operational voltage.

If this happens however, then when the external battery is replaced and the supply voltage is restored, SBSFU logs the following:

= [SBOOT] System Security Check

= [SBOOT] System Security Check successfully passed. Starting...

======================================================================

= =

= Secure Boot and Secure Firmware Update =

======================================================================

= [SBOOT] SECURE ENGINE INITIALIZATION SUCCESSFUL

= [SBOOT] STATE: CHECK STATUS ON RESET

INFO: A Reboot has been triggered by a Hardware reset!

= [SBOOT] STATE: CHECK NEW FIRMWARE TO DOWNLOAD

= [SBOOT] STATE: CHECK KMS BLOB TO INSTALL

= [SBOOT] STATE: CHECK USER FW STATUS

No valid FW found in the active slots nor new FW to be installed

Waiting for the local download to start...

= [SBOOT] STATE: DOWNLOAD NEW USER FIRMWARE

File> Transfer> YMODEM> Send .........

So for some reason, after the supply voltage has dropped below a valid operational voltage, it seems that my firmware is deleted for some reason. There is nothing wrong with my hardware, I can reflash with the STM32CubeProgrammer and then everything returns back to normal.

I'm completely mystified by this, how can it be that a too low supply voltage seemingly deletes what is in the flash?

This is a huge problem for me, as I cannot avoid this, and products that experience this cannot be restored remotely with OTA. So this means a product recall.

@Jocelyn RICARD Do you perhaps have an idea what can cause this?

MM..1 · ‎2022-07-22

I see two possible fail

your fw is not marked as valid and active after you load it
sbsfu erase it

check real flash data in your MCU before flash with cubeprog, but if RDP is active ...

MBax.2 · ‎2022-07-22

After my firmware boots, it checks the firmware state with SE_APP_GetActiveFwState and if needed it calls SE_APP_ValidateFw to mark the firmware as valid, so your possible fail #1 is unlikely. I'm also using RDP so I cannot check what is going on when SBSFU reports "No valid FW found in the active slots nor new FW to be installed".

Upon further investigation I have also seen this case once for a product of which the battery was not depleted. I'm now trying to set something up so that I can reproduce this problem quickly. Currently the bug frequency seems to depend on the battery lifetime which is long, making it hard to reproduce.

MBax.2 · ‎2022-07-22

While attempting to set something up to reproduce this problem consistently, I ran into another SBSFU issue, possibly related. When the battery drops below a critical level. The supply voltage is cut off to prevent deep discharge. This also cuts the load, which then results into the battery voltage restoring a little, which then increases the voltage to above the critical level and the power is enabled again. This quickly cycles quite a few times before eventually the cycle stops until the voltage does not restore to above the critical level anymore.

In the first iteration of this cycle SBSFU gives a tampering fault:

= [SBOOT] SECURE ENGINE INITIALIZATION SUCCESSFUL

= [SBOOT] STATE: CHECK STATUS ON RESET

INFO: A Reboot has been triggered by a Hardware reset!

= [SBOOT] STATE: CHECK NEW FIRMWARE TO DOWNLOAD

= [SBOOT] STATE: CHECK KMS BLOB TO INSTALL

= [SBOOT] STATE: CHECK USER FW STATUS

A FW is detected in the slot SLOT_ACTIVE_1

= [SBOOT] STATE: VERIFY USER FW SIGNATURE

= [SBOOT] LOADING CERTS FROM SECURE ENGINEOK

= [SBOOT] Verifying the Certificate chain...

Tampering fault

========= End of Execution ==========

Then the following cycles give the following log, which is in-line with what I would expect:

======================================================================

= =

= Secure Boot and Secure Firmware Update =

======================================================================

= [SBOOT] SECURE ENGINE INITIALIZATION SUCCESSFUL

= [SBOOT] STATE: CHECK STATUS ON RESET

INFO: A Reboot has been triggered by a Hardware reset!

= [SBOOT] STATE: CHECK NEW FIRMWARE TO DOWNLOAD

= [SBOOT] STATE: CHECK KMS BLOB TO INSTALL

= [SBOOT] STATE: CHECK USER FW STATUS

A FW is detected in the slot SLOT_ACTIVE_1

= [SBOOT] STATE: VERIFY USER FW SIGNATURE

= [SBOOT] LOADING CERTS FROM SECURE ENGINEOK

= [SBOOT] Verifying the Certificate chain...

= [SBOOT] System Security Check successfully passed. Starting...

However after a whole bunch of cycles SBSFU then logs this:

= [SBOOT] SECURE ENGINE INITIALIZATION SUCCESSFUL

= [SBOOT] STATE: CHECK STATUS ON RESET

WARNING: A Reboot has been triggered by a Firewall reset!

= [SBOOT] STATE: CHECK NEW FIRMWARE TO DOWNLOAD

= [SBOOT] STATE: CHECK KMS BLOB TO INSTALL

= [SBOOT] STATE: CHECK USER FW STATUS

A FW is detected in the slot SLOT_ACTIVE_1

= [SBOOT] STATE: VERIFY USER FW SIGNATURE

= [SBOOT] LOADING CERTS FROM SECURE ENGINEOK

= [SBOOT] Verifying the Certificate chain...

= [SBOOT] System Security Check successfully passed. Starting...

After this, when the battery is fully recharged and the supply voltage is good and continuous again, SBSFU is trapped in an endless loop continuously rebooting with the message "WARNING: A Reboot has been triggered by a Firewall reset!".

I do need to add a hysteresis to the battery protection circuit to prevent the power to be restored before a charge has been started, but this SBSFU error should not occur right?

This might be related to SBSFU sometimes deleting my firmware, though I have not found a method yet to consistently reproduce that.

MBax.2 · ‎2022-07-23

I've increased the hardware battery protection hysteresis which resolves the device getting stuck in an endless SBSFU loop of "WARNING: A Reboot has been triggered by a Firewall reset!". I do think however that this is unrelated to the problem I have seen where the firmware was deleted for an unknown reason, since that also happened with a full battery.

So I'm still trying to find a way to reproduce that.