Downloaded Image verification failed status

[SPati.7]

Do we have any mechanism to know about Software validation check status ??

in case of reset, SBSFU will check for validity of application, before jumps to it. And in case of fail, it won't launch application, The failure status, how can we know ??

Do we have any recovery mechanism, if signing verification failed and we don't have application running to download new firmware ??

[Bubbles]

Hi @SPati.7​ ,

in case of a dual image solution, there is always a backup application. In case of single image, the SBSFU can implement various recovery mechanisms. A basic one is even part of the example code.

BR,

J

[Fred]

If the question is more about the validation status and the failure status, you can use the table provided in UM2262 section 9 "Understanding the last execution status message at boot-up "

In the code, you will see some calls like this:

 e_ret_status = VerifyFwSignatureAfterDecrypt(&e_se_status, DwlSlot, pFwImageHeader);

 if (e_ret_status != SFU_SUCCESS)

 {

  SFU_EXCPT_SetError(SFU_EXCPT_SIGNATURE_ERR);

 }

You can then check in sfu_error.c how this is converted to a debug string:

#ifdef SFU_DEBUG_MODE

/**

 * The following strings associated to the exceptions/errors are used for debugging purpose.

 * WARNING: The string array must match perfectly with the @ref SFU_EXCPT_IdTypeDef.

 * And the @ref SFU_EXCPT_IdTypeDef enum must be a sequence starting from 0

 */

static char *m_aErrorStrings[] ={ "No error. Success",

[SPati.7]

@Fred​ As you mentioned above, if any failure and debug mode is enabled, then we may be able to see data on Debug port. But what happens, if we don't have enable DEBUG and still need to store status as persistent, to further process, whenever application running ??

In case of DUAL image solution, there will be always backup exist as mentioned by @JHOUD​, is it mean like one ACT SLOT & DNLD SLOT ?? or 2 SLOTS for Active and Download image ??

Assume, VER1 is running ACT SLOT 1, VER2 is downloaded in DNLD SLOT 1, and then it went for reboot. VER2 will be installed if everything check succeeded.

In case of further power cycles, if ACT SLOT application failed to run, then are we going to copy from DNLD SLOT1 ??

On overall, can you help with this remote upgrade mechanism ??

[Fred]

The general principle when installing a new firmware image is indeed to proceed with a swap of the active slot and the download slot (if you have only 2 images configured).

Initially, this feature has been designed in case of power shortage during the installation procedure.

This way, we were able to do a recovery to the previous firmware image if something went wrong.

We were also using it in case the new firmware image faced too many errors, to be able to do a rollback to previous version.

But, as you know, X-CUBE-SBSFU has been audited by a security lab. They considered that these rollback and recovery mechanisms were a way for an attacker (via a power off during firmware update for instance) to prevent a firmware update from being completed and to revert to previous firmware image.

So, we updated the implementation and now if a power off occurs during the firmware update procedure then we resume the installation of the new firmware image (except if the power down occurred during the decrypt operation that we cannot resume as the decrypt context is not saved).

Also, we do not do a rollback any more in case of errors with the new image.

Nevertheless, the code doing the swap is still present and for some specific needs we have implemented an "image state" management logic:

#if defined(ENABLE_IMAGE_STATE_HANDLING) && !defined(SFU_NO_SWAP)

    /* Move the state to SELFTEST for the new images */

    if (SFU_IMG_UpdateImageState(SLOT_ACTIVE_1 + i) != SFU_SUCCESS)

    {

     /* Image state cannot be changed : What to do ?

       ==> decision to continue execution */

     TRACE("\r\n= [FWIMG] WARNING: IMAGE STATE CANNOT BE CHANGED!");

    }

#endif /* ENABLE_IMAGE_STATE_HANDLING && !(SFU_NO_SWAP) */

You can get more information about it in UM2262, Appendix J.

But, please keep in mind that this can be seen as an attack opportunity, so you need to analyze if you want to use it or not.

[SPati.7]

@Fred​  Thanks for your quick reply.

As per my understanding, even if we keep ACT SLOT and DNLD SLOT as active, DNLD SLOT may not be considered as backup, in case of DNLD SLOT it self got bad image right ??

So, if ACT_SLOT application got corrupted, then we may use DNLD SLOT if it is in Good.

If there is no proper application at all, either ACT SLOT or DNLD SLOT, then we need to fallback SBSFU internal Loader which accepts application from UART through Y-Modem ??

is this enabling UART port from SBSFU, is not a RISK. Can be exploited by attckers right ?? is it accepted as Secure Solution ??

[Fred]

Yes, you can check Appendix J figure 66 in UM2262:

If the previous firmware image is not tagged valid then we end up in local loader mode.

Nevertheless, if the firmware got corrupted without the valid state being updated then maybe you can revert to an invalid firmware. You must check this kind of cases.

Using UART increases the attack surface, so yes you open the door to new risks.

You must assess carefully the code dealing with the UART communication and decide if you trust it or not.

As soon as you transfer data, you deal with buffers so you can have bugs in this area leading to security breaches.

So, you need to:

• assess this code
• assess the overall security strategy : what if somebody takes control of the system from this code ? Can he access sensitive data or perform unauthorized operations ?
• ...any other assessment you think may be needed depending on your requirements...

Here, you need to do this kind of assessments.

[SPati.7]

@Fred​  Are we storing this status in Memory somewhere ?? If we see IMG_STATE_HANDLING feature, we are processing in SBSFU and Application context as well ??

Do we have any secure way to share data between SBSFU and User Application ??