Can SBSFU internal loader enabled in RDP_LVL 2 mode ??

[SPati.7]

We have plan to support application down-loader from Application context. It means Application has ability to receive new application over the air. Not SBSFU.

In case of Active application got corrupted somehow, then SBSFU is locked the MCU, as we lost Remote application upgrade capability.

Can we enable SBSFU internal loader in case of recovery mechanism condition only, as No valid application exist ?? if we enable, the what is the RISC of Security ??

[Jocelyn RICARD]

Hello @SPati.7​ ,

Yes this is the purpose of this loader.

Besides, the implementation of SBSFU provides either a local loader or a standalone loader. This standalone loader is available or not depending on examples.

Local loader is inside SBSFU.

Standalone loader is a separate application launched by SBSFU when no valid image is found.

The SBSFU is using internal isolation mechanism (MPU or firewall) reducing the risk of successful attack through the loader interface.

In the examples, the activation of the local or standalone loader can be forced by pressing the user button of the board while resetting.

I hope this answers your question

Best regards

Jocelyn

[SPati.7]

@Jocelyn RICARD​ As you said internal loader enable us to download application, but it need UART interface, is this not open for attack ??

Also, Standalone loader means is a specific loader we need to built apart from Application loader ?? i meant we are going to have customised application loader, responsible for remote upgrade.

is it prefer to use existing SBSFU internal loader as it is, as customizing SBSFU to meet our download requirements is going to do lot of modifications ??

How Anti rollback works ?? if new application doesn't start ??

Also, Can we disable local loader and on specific case, can we call download module ??

Total how many types of loaders available in SBSFU ?? Can you please help with these ?? I am really looking information on detailed remote upgrade how it happens in case of anti roll back or internal loader or any thing ?? We are looking to apply DUAL_SLOT Config.

[Jocelyn RICARD]

Hello @SPati.7​ ,

Any communication means increases the surface of attack of a device.

So, yes, using an additional means raises the risk of attack.

Now, UART interface is extremely simple compared to remote access. So, the importance of the risk is quite low. Also, you need a local access to the device.

You can use the SBSFU internal loader as it is, this is the easiest way.

Internal loader behaves exactly the same way as your application loader. It will copy the updated firmware in download slot, so, it follows same rules for antirollback.

You can experience this with the examples we provide.

If you want to disable the local loader, you can add a code in SBSFU that will enable it only if no authenticated image is available.

In term of loaders as I said, SBSFU provides

Local SBSFU loader (part of SBSFU code)

Standalone loader (specific application dedicated to loading)

Application loader (in UserApp example)

The standalone loader is available in some examples and is exclusive from Local loader.

The antirollback mechanism is only used when you try to update a firmware with an lower version.

For instance trying to update a running firmware having version 2 with a version 1 will fail before installation.

To handle issue related to a newly installed firmware that is actually not working, you have the image state handling feature.

Principle is to perform a kind of auto test in the newly installed firmware and call specific API to change the image state. If this call is not done, on next reset, SBSFU will rollback to previous version that is working correctly.

Best regards

Jocelyn

[SPati.7]

It means, Version 1 can be fail (assume version lower or application corrupted), then we are not going to install new application. This is fine. Version 2 only will be running.

But, one more case Version 2 is running (means in ACT SLOT), and it got corrupted due to some unexpected reasons. then what is the fallback mechanism, whether anti roll back works here ??

OR it switch to local LOADER only ??

Antirollback feature will be effective when we have backup application on some other download slot location, not the ACT SLOT right ?? It means we need to configure more than one download slot ??

When are we going to erase DNLD_SLOT_1 application ??

[Fred]

If both version 1 and version 2 get corrupted, then even using the image state handling is useless because you have no valid image any more.

In this case, you need to go trough the local loader again to install version 3.

Nevertheless, if the firmware header gets corrupted, then there is a special define to indicate which version is authorized to be installed:

#define SFU_FW_VERSION_INIT_NUM (1U)   /*!< The version number accepted when the header is not valid (either because

                       no FW installed or due to an attack attempt). Could be different from

                       SFU_FW_VERSION_START_NUM */

[SPati.7]

@Fred​  are we going to erase DNLD SLOT application after swap with ACT SLOT application ??

Swap means, DNLD SLOT will be replaced with ACT SLOT application vice versa ?? that's why we are talking about ROLL_BACK mechanism as we can replace ACT SLOT with older version ??

[Fred]

Indeed, when swapping you exchange both data.

Say you have firmware N in active slot and firmware N-1 in download slot.

If you upgrade to Firmware N+1:

• first, you store Firmware N+1 in download slot: Firmware N-1 is lost
• then, you swap the active slot and download slot
• Active slot now contains Firmware N+1 and download slot (which is also the backup slot) contains Firmware N

So you can only revert to version N (N-1 is not on your device any more).

This is what you can do with what we provide.

Now, you may very well decide to store a "golden firmware image" in a third slot.

You can even protect this slot with WRP to make sure your golden firmware image is never corrupted.

Then, if you face issues with the active slot, you can very well decide to reinstall the golden image.

From this image you can move to the latest and greatest software.

But we do not provide any example of this kind of strategy.

[SPati.7]

@Fred​ Thanks for clear details.

If we configure more SLOTS, again we need to compromise on FLASH availability as well right.

As of now, we are using STM32H7, where we have only Internal FLASH with capacity of 2 MB.

So, final take away on antiroll_back mechanism, is not recommended as per security labs, eventhough if we consider rollback only in certain cases like power cycle, but still it is risky ??

[Fred]

The security lab that audited X-CUBE-SBSFU did not recommend it because it is a way to go back to a previous firmware version.

But, as usual, security is a trade-off depending on what you need : for instance I think that some IoT solutions do implement the rollback to avoid ending up with a bricked device.

So, here I would say that you are "alone" with your requirements : this is your responsibility :)

[SPati.7]

@Fred​ Thanks for your deep insights and understandings. These details are really very helpful for us :smiling_face_with_smiling_eyes: .

Yeash, understood, the design should by defined by us, i think to avoid bricked device, in case of invalid application or NO application, we may take SBSFU local LOADER approach.

Thanks Again.

[Fred]

First of all, if you want to experiment the anti-rollback feature, you must not enable ENABLE_IMAGE_STATE_HANDLING. Otherwise, a rollback might occur if the new image is not validated.

This being said, experimenting this feature is not described in the UM2262, but you can do it easily.

Let's assume you have compiled all the projects and installed a version 1 of the User application.

What you can do is:

1.Open the UserApp project in the IDE

2. Change the version in the postbuild step:

cmd /C "cmd /C $PROJ_DIR$\..\..\2_Images_SECoreBin\EWARM\PostBuild.bat "$PROJ_DIR$" "$TARGET_PATH$" "$PROJ_DIR$\UserApp.bin" 1 1" ==> put 2 instead of 1 for the last parameter

3. Install this new version (fw version = 2) and save the .sfb as firmware_version2.sfb

4. Back to UserApp project in iht eIDE, tune the postbuild step to create version 3

5. Install version 3

6. Check that if you try to reinstall version 2, it is rejected (try installing firmware_version2)

7. Clean-up your board and reinstall version 2

8. Start installing version 3, execute a RESET (press black button) after decrypt, while the swap is in progress: after RESET, the installation should be resumed and firmware 3 should be installed.

(Alternate option: you can do the RESET during the decrypt, in this case the installation should not be resumed as we cannot resume the decrypt operation).

[SPati.7]

Yes @Fred​ I experimented whatever you said, it is working fine.

But in the production field, if you want us to implement rollback feature, need to enable IMAGE_STATE_HANDLING feature right ??

if so, what kind of changes needed in application to validate the firmware image ??