Problems on enabling TF-M's BL2

RE: Problems on enabling TF-M's BL2

Einar Thorsrud — Tue, 19 Oct 2021 08:26:38 GMT

Hi,

Yes, we do not have a solution for FWU for secure partitions only at the moment. Support for TF-M in nRF Connect SDK is still experimental and some important functionality is still missing. I cannot say which approach we will use for firmware upgrades of secure partitions at the moment, but the team is looking into this.

Edit: Note that we use a swapping mechanism with MCUboot so that the banked update is stored in a non-secure area. Therefore the application can write the update itself without using a secure service. We bundle TF-M together with the app image, so the current mechanism can be used to update both together.

RE: Problems on enabling TF-M's BL2

jli157@intel — Mon, 18 Oct 2021 16:36:30 GMT

Einar,

You mean you haven't enabled the firmware update secure partitions (FWU) for firmware update? So, what's Nordic's plan to support FWU? You will use another approach instead of FWU provided by TF-M?

RE: Problems on enabling TF-M's BL2

Einar Thorsrud — Tue, 12 Oct 2021 09:55:54 GMT

Hi,

We do not currently have any solution for updating only the secure partition. I have asked the team working on it to look into it.

For now, you can either enable serial recovery in MCUBoot or use the dfu_target_mcuboot APIs or direct flash read/write to secondary partition (dfu_target_mcuboot.c). Or see in dfu_target_stream.c how it's implemented there with flash read/writes. Then to set the image as active you would have to use mcuboot.h if you use flash write/read operations directly.

RE: Problems on enabling TF-M's BL2

jli157@intel — Tue, 12 Oct 2021 07:53:14 GMT

We are thinking to use the firmware update secure partition from TF-M to do the firmware update in the future, which means the Zephyr application will use the firmware update TF-M APIs to populate new firmware data to the secondary partitions. What's your suggestions for this feature?

Okay, I'll open a new ticket for other questions for nrf_security.

RE: Problems on enabling TF-M's BL2

Einar Thorsrud — Fri, 08 Oct 2021 11:22:51 GMT

Hi,

[quote user="bleintel"]I just realized that nrfsdk-mcuboot is actually used by Nordic to replace TF-M's BL2 thus the BL2 inside TF-M is disabled. So, will you continue this way in the future or you will enable TF-M's BL2 at sometime? [/quote]

There are no work on supporting BL2 now. I cannot say if it will come at some point in the future or not, though.

[quote user="bleintel"]I saw BL2 inside TF-M has some special customized code based on mcuboot, like the shared data with Firmware Update secure partition. Does nrfsdk-mcuboot work with firmware update secure partition? Or you have another plan to support firmware update? [/quote]

Perhaps you can elaborate? Is the question here if/how you can update TF-M?

[quote user="bleintel"]Does nrfsdk-mcuboot support using QSPI flash memory as the swap storage on nrf53 DK? [/quote]

Yes, you can have the secondary slot (1) on external flash, and then copy it to slot 0 during activation.

[quote user="bleintel"]However, I'm wondering why Nordic chose using the static library instead of the package "cryptocell-312-runtime" inside TF-M to enable CryptoCell for TF-M? Are there some special considerations or some limitations? [/quote]

The cryptocell-312-runtime is provided by ARM for use on some other devices, but it not and cannot be used on Nordic devices. The nrf_cc312_mbedcrypto is based on ARM libraries but has (among other things) adaptations for the nRF platform.

[quote user="bleintel"]Is it okay I'm using the same thread to ask more questions about nrf_security? I'm still having a couple of questions. Or should I open a new thread? [/quote]

I would prefer it if you make a new thread for separate questions. That makes it easier to maintain the overview, and also makes it easier to delegate some questions to other colleagues of mine.

Einar

RE: Problems on enabling TF-M's BL2

jli157@intel — Thu, 07 Oct 2021 15:52:08 GMT

Hi Einar,

Thanks for the support again!

I just realized that nrfsdk-mcuboot is actually used by Nordic to replace TF-M's BL2 thus the BL2 inside TF-M is disabled. So, will you continue this way in the future or you will enable TF-M's BL2 at sometime?

I saw BL2 inside TF-M has some special customized code based on mcuboot, like the shared data with Firmware Update secure partition. Does nrfsdk-mcuboot work with firmware update secure partition? Or you have another plan to support firmware update?

Does nrfsdk-mcuboot support using QSPI flash memory as the swap storage on nrf53 DK?

As for nrf_security, yes I also found the build script extracts the library nrfxlib/crypto/nrf_cc312_mbedcrypto/lib/cortex-m33/soft-float/no-interrupts/libnrf_cc312_mbedcrypto_0.9.11.a and chooses the object files based on the enabled macros.

However, I'm wondering why Nordic chose using the static library instead of the package "cryptocell-312-runtime" inside TF-M to enable CryptoCell for TF-M? Are there some special considerations or some limitations?

Is it okay I'm using the same thread to ask more questions about nrf_security? I'm still having a couple of questions. Or should I open a new thread?

RE: Problems on enabling TF-M's BL2

Einar Thorsrud — Thu, 07 Oct 2021 13:32:41 GMT

Hi,

BL2 is not supported with TF-M right now. You can use BOOTLOADER_MCUBOOT instead for now. Can you elaborate on what you mean by MCUBoot not being well aligned to TF-M?

Regarding nrf_security, the CryptoCell is enabled by default when you use TF-M. Checking the build/tfm/build.ninja file will show the linking commands with the crypto libraries.