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.

[Elfving]

Not that I can think of. Though it is a workaround - security shouldn't be a main concern yet. All issues are to be fixed before it is production-ready, which is probably why it states that it is not supported. 

Riku Karttunen said:

"We currently do not support builds with MCUboot and TF-M if the Nordic Security backend is used."

I'll have to look into that and get back to you. But in any case, support for CONFIG_TFM_BL2 will eventually be dropped and replaced by CONFIG_BOOTLOADER_MCUBOOT.

Best regards,

Elfving

Just a small update:

There are no issues with the nordic security backend, but there is currently one minor issue with MCUboot, that the above workaround addresses.

The documentation can be a bit confusing, but BL2 isn't and will not be supported.

[Riku Karttunen]

Hey again,

Thanks for the updates. I'll add here my quick test results should they help someone trying to integrate similar things.

I enabled MCUboot and applied those config options you mentioned to the MCUboot subimage. Build went through fine and I ended up with 3 subimages (mcuboot, tfm, zephyr). I then flashed the merged image and was greeted with the following prints:

*** Booting Zephyr OS build v2.6.99-ncs1  ***
I: Starting bootloader
I: Bootloader chainload address offset: 0xc000
ASSERTION FAIL [!sys_dnode_is_linked(&to->node)] @ WEST_TOPDIR/zephyr/kernel/timeout.c:93

I don't know what to make of this assertion. Do you have any pointers for what could be the issue? I am using a custom board so my hunch is that this has to do with my specific board/config/memory combination.

[Elfving]

Hmm no that error is a bit new to me.

It could be the custom board. Could you try it with a DK as well to verify if that is the case?

Best regards,

Elfving

[Riku Karttunen]

Hey,

I've done some more testing and it seems that I'm missing something when trying to add MCUboot to an app that is using TF-M. For example my own custom application on a custom board ends up stuck in a hard fault handler or somewhere completely random place in the code (seen when printing backtrace after attaching to the frozen app with a debugger) straight from boot. All I can see before that is this:

*** Booting Zephyr OS build v2.6.99-ncs1  ***
I: Starting bootloader
I: Bootloader chainload address offset: 0xc000
I: Jumping to the first image slot

I also did a quick test with Zephyr's tfm_ipc sample where I just added CONFIG_BOOTLOADER_MCUBOOT=y. This resulted in a boot loop repeating these messages:

*** 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: 0x10000
I: Jumping to the first image slot

I don't know if this boot loop and the situation of my own application are related in any way but it feels like this could be the same problem but different symptoms. It seems that I'm missing something important when trying to integrate MCUboot + TF-M. Can you see anything obviously wrong here and do you have any pointers on how to do this kind of integration?

The board I used in my own application is a custom one but it is equivalent to nrf9160dk except the peripherals are different. I used nrf9160dk when testing with the tfm_ipc sample.

[Elfving]

Hey again Riku!

Yes, this second error is familiar. It might occur because you don't disable FPROTECT and ARM_MPU on the MCUBoot image. Though it is a bit hard to say, as TF-M will reboot on an internal error, so it could be anything really. 

Riku Karttunen said:

I don't know if this boot loop and the situation of my own application are related in any way but it feels like this could be the same problem but different symptoms.

Well I am not sure about the first error, but does this help anything?

Best regards,

Elfving

[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.