signed_by_b0_s1_image.bin vs signed_by_mcuboot_and_b0_s1_image_update.bin

RE: signed_by_b0_s1_image.bin vs signed_by_mcuboot_and_b0_s1_image_update.bin

AHaug — Wed, 25 Jan 2023 11:39:22 GMT

Hi,

[quote user="brandon_ask_questions"]

AFIAIK the reason for why MCUboot will require signatures to authenticate is since MCUboot is handling the image swapping.

But there is no image swapping for updating MCUBoot.

[/quote]

Good thing you followed up on this, because I see I was a bit unclear/too fast with this comment, so I'll expand on this some more: It's correct that there are no swapping, but the signature is not only for the transport of the image. B0 checks versions and chooses that MCUboot version which is the newest version. Then b0 validates that MCUboot version before it boots. It can validate with both signature and/or hash, but the default is signature.

This sample should illustrate how it's done: https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bootloader/src/main.c

Please feel free to ask more questions if you still have anything unanswered

Kind regards,
Andreas

RE: signed_by_b0_s1_image.bin vs signed_by_mcuboot_and_b0_s1_image_update.bin

brandon_ask_questions — Tue, 24 Jan 2023 22:12:09 GMT

Thank you for the thorough response.

[quote userid="107683" url="~/f/nordic-q-a/95700/signed_by_b0_s1_image-bin-vs-signed_by_mcuboot_and_b0_s1_image_update-bin/405976"]Also its worth noting this about the app primary/secondary slot: per documentation about image slots[/quote]

I understand that MCUBoot authenticates and swaps the contents in mcuboot_secondary and mcuboot_primary to perform a update.

[quote userid="107683" url="~/f/nordic-q-a/95700/signed_by_b0_s1_image-bin-vs-signed_by_mcuboot_and_b0_s1_image_update-bin/405976"]AFIAIK the reason for why MCUboot will require signatures to authenticate is since MCUboot is handling the image swapping.[/quote]

But there is no image swapping for updating MCUBoot. The file name "signed_by_mcuboot_and_b0_s0_image_update.bin" implies that there is swapping or MCUBoot is authenticating the s0/s1 update prior to writing.

My interpretation is that it is signed by MCUBoot purely to make the fota_download library compatible and not fail the target check. I am not using the fota_download library and my conf does not have it enabled.

RE: signed_by_b0_s1_image.bin vs signed_by_mcuboot_and_b0_s1_image_update.bin

AHaug — Mon, 23 Jan 2023 09:10:09 GMT

Hi,

Apologies for the delayed response time, I've been out of office since last week.

[quote user="brandon_ask_questions"]when OTA'ing a MCUBoot is "signed_by_mcuboot_and_b0_s0_image_update.bin" written by the main application to the mucboot_secondary Application slot or s0?[/quote]

They are written for s0 (or s1 for signed_by_x_s1_image_update.bin") per MCUboot output build files, and has nothing to do with the primary or secondary application slot (which are reserved for the application itself).

As an example (to attempt) to illustrate this: In your firmware with an updatable bootloader you will have a B0, S0 and S1 slot in addition to the application slot(s). In FW v.1, you will run the immutable bootloader in b0 and the second stage bootloader in S0. The immutable bootloader will ensure that itself runs first, followed by whatever is in S0, then it will run the application.

If you want to update the bootloader in FW v.2 you will have to use "signed_by_mcuboot_and_b0_s1_image_update" to put the new instance of MCUboot in S1. The immutable bootloader (b0) will now update to run itself first, then use s1 (and ignore s0), and then the app.

If you want to update the bootloader yet again in FW v.3 you will need to use s0_image_update and put the new instance of MCUboot in s0 and now you will overwrite the first instance of mcuboot stored in s0. This procedure repeats for FW v.X.

Also its worth noting this about the app primary/secondary slot: per documentation about image slots "Normally, the bootloader will only run an image from the primary slot, so images must be built such that they can run from that fixed location in flash (the exception to this is the direct-xip and the ram-load upgrade mode). If the bootloader needs to run the image resident in the secondary slot, it must copy its contents into the primary slot before doing so, either by swapping the two images or by overwriting the contents of the primary slot."

[quote user="brandon_ask_questions"]I am confused on why it is signed by MCUboot sense MCUBoot isnt authenticating "signed_by_mcuboot_and_b0_s0_image_update.bin" (i.e. bootchain is b0->mcuboot->app)[/quote]

AFIAIK the reason for why MCUboot will require signatures to authenticate is since MCUboot is handling the image swapping.

Let me know if this clarifies things for you!

Kind regards,
Andreas

RE: signed_by_b0_s1_image.bin vs signed_by_mcuboot_and_b0_s1_image_update.bin

brandon_ask_questions — Tue, 17 Jan 2023 15:26:16 GMT

Hi AHaug,

Thanks for answering.

Another question, when OTA'ing a MCUBoot is "signed_by_mcuboot_and_b0_s0_image_update.bin" written by the main application to the mucboot_secondary Application slot or s0? I am confused on why it is signed by MCUboot sense MCUBoot isnt authenticating "signed_by_mcuboot_and_b0_s0_image_update.bin" (i.e. bootchain is b0->mcuboot->app)

RE: signed_by_b0_s1_image.bin vs signed_by_mcuboot_and_b0_s1_image_update.bin

AHaug — Tue, 17 Jan 2023 08:26:21 GMT

Hi,

We have https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_build_system.html which describes signed_by_mcuboot_and_b0_s0_image_update (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_build_system.html#mcuboot-output-build-files), which is the image you will want to use.

If you examine CMake, then you can see that signed_by_b0_ is generated in sign.cmake and is later used in nrf/modules/mcuboot/CMakeLists.txt to generate signed_by_mcuboot_and_b0

You will want to use signed_by_b0 if you use NSIB as the only bootloader, ref this (unofficial) sample: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/updatable_bootloader/nsib_simple

I know that this documentation is hard to find, and I will have a chat with our tech writers if we can add some documentation about signed_by_b0_image in the build system page I linked at the top

Let me know if this answers your questions!

Kind regards,
Andreas