What are the options for using TF-M with MCUboot?

[Riku Karttunen]

Hi,

I would like to use MCUboot together with TF-M for an application running on nRF9160 in order to have the security features provided by TF-M while having upgrade capabilities. I can see that currently there are limitations when it comes to using the Nordic security backend + TF-M + MCUboot. What are my options for making this combination (TF-M + MCUboot) work currently? Is there an alternative to the Nordic backend and how would it differ if so? Can we expect the limitation regarding the Nordic backend to be removed any time soon?

[Elfving]

Hey again Riku!

TF-M + MCUboot) work currently?

Yes! This is possible with NCS1.7, but there are some issues. Currently as a workaround, CONFIG_ARM_MPU and CONFIG_FPROTECT must be disabled on the MCUBoot image.

Can we expect the limitation regarding the Nordic backend to be removed any time soon?

It is expected to be fixed shortly. Are there any other limitations you are referring to? 

Best regards,

Elfving

[Riku Karttunen]

Thanks, I'll add those options to the configuration during development. Does disabling those features have any negative effects on the whole system (security especially)?

The limitation I was referring to was the one specified in the help text of the CONFIG_TFM_BL2 option stating "We currently do not support builds with MCUboot and TF-M if the Nordic Security backend is used." I suppose this has to do with different instance of MCUboot than the one you are referring to.

[Riku Karttunen]

Hey,

I managed to get both the sample and my application booting successfully into the application and everything seems to work nicely. The key was CONFIG_MCUBOOT_CLEANUP_ARM_CORE=y.

Now the way I ended up with this solution doesn't make sense to me. When I build the tfm_ipc sample with these changes

diff --git a/samples/tfm_integration/tfm_ipc/mcuboot_overlay.conf b/samples/tfm_integration/tfm_ipc/mcuboot_overlay.conf
new file mode 100644
index 0000000000..c8ecce2427
--- /dev/null
+++ b/samples/tfm_integration/tfm_ipc/mcuboot_overlay.conf
@@ -0,0 +1,2 @@
+CONFIG_FPROTECT=n
+CONFIG_ARM_MPU=n
diff --git a/samples/tfm_integration/tfm_ipc/prj.conf b/samples/tfm_integration/tfm_ipc/prj.conf
index 7a4c680c6c..d5ba8884f5 100644
--- a/samples/tfm_integration/tfm_ipc/prj.conf
+++ b/samples/tfm_integration/tfm_ipc/prj.conf
@@ -1,6 +1,7 @@
 CONFIG_BUILD_WITH_TFM=y
 CONFIG_TFM_IPC=y
 CONFIG_REBOOT=y
+CONFIG_BOOTLOADER_MCUBOOT=y
 
 # The Zephyr CMSIS emulation assumes that ticks are ms, currently
 CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000

and this build command

west build -p -b nrf9160dk_nrf9160_ns -- -Dmcuboot_OVERLAY_CONFIG=$(pwd)/mcuboot_overlay.conf

the sample ends up in a hard fault handler with these prints

*** Booting Zephyr OS build v2.6.99-ncs1  ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
I: Jumping to the first image slot

Now when I apply those two overlay config options via the command line like this

west build -p -b nrf9160dk_nrf9160_ns -- -Dmcuboot_CONFIG_FPROTECT=n -Dmcuboot_CONFIG_ARM_MPU=n

the sample works perfectly fine.

I checked the diff for .config of those two builds and the only thing that changes is that CONFIG_MCUBOOT_CLEANUP_ARM_CORE=y gets set in the one where I pass the options via the command line. Why does this happen? I'm using the current sdk-nrf master branch (a8100e9bd0a602365fe86a8248d233017cab0c50) without any changes to the revisions in sdk-nrf west.yml.

[Elfving]

Hey Riku!

Ah right, seems that I forgot about CONFIG_MCUBOOT_CLEANUP_ARM_CORE. You would need that as well. I am a bit surprised it wasn't added automatically in the master branch though. You said you were using the master for both of those cases?

Best regards,

Elfving

[Riku Karttunen]

This is completely reproducible (on nRF9160 DK) with a fresh source by running

west init -m https://github.com/nrfconnect/sdk-nrf --mr master

and applying the patch + using the instructions in my previous post.

I'd like to understand why applying the config options from the command line behaves differently versus applying them from an overlay file. Having no idea why this happens may result in some pretty nasty unexpected behaviour down the line.

[Elfving]

Riku Karttunen said:

This is completely reproducible

Yes, I see that now. add_overlay_config is ignored when -D<child_image>_OVERLAY_CONFIG=foo.conf is used. We would expect foo.conf to be appended to the set of overlays, not to replace them.

It is a bug, and we will be dealing with it shortly.

Best regards,

Elfving

[Torsten Rasmussen]

> This is completely reproducible (on nRF9160 DK) with a fresh source by running

Please find a fix here: github.com/.../5806

[Torsten Rasmussen]

Reported to Kitware as a CMake bug: https://gitlab.kitware.com/cmake/cmake/-/issues/22734