Confirmation Question: Can MCUboot be made an immutable bootloader in the nRF52840 IC?

[Canadian_EE]

Hi, 

   I am reading through different Nordic documentation. In some documentation, it shows a first stage B0 Nordic bootloader. This bootloader then can point to MCUboot as the Second Stage Bootloader. 

On the other hand, I see documentation indicating that MCUboot can be the First Stage Bootloader. 

    I would like to confirm

1. Can MCUboot be the First Stage Bootloader?

2. Can MCUboot be immutable? Meaning write protected? 

3. Does Secure MCUboot mean the MCUboot bootloader is immutable? Is Secure Boot == Immutable Bootloader? Or does Secure Boot mean something else? 

Also

4. Can image files be encrypted while still maintaining a Secure Immutable MCUboot bootloader? Some sources say that encrypted images are not supported. 

5. Do I need to modify MCUboot to provide read protection for the firmware? 

6. Can I get (4) and (5) with a single image slot? I don't want to waste space on a second image slot. 

[Vidar Berg]

Hello,

1. Can MCUboot be the First Stage Bootloader?

Yes, mcuboot will be used as the first stage bootloader as long as you don't enable the Nordic Secure immutable bootloader (B0).

2. Can MCUboot be immutable? Meaning write protected? 

Yes, write protection is enabled by default (CONFIG_FPOTECT):  https://github.com/nrfconnect/sdk-mcuboot/blob/16a77893d9c6c461f79178b2148159e32949d9ac/boot/zephyr/main.c#L610 

3. Does Secure MCUboot mean the MCUboot bootloader is immutable? Is Secure Boot == Immutable Bootloader? Or does Secure Boot mean something else?

The bootloader must also validate the signature of the next image in the boot chain (in this case, the application image). You can read more about this here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader.html

4. Can image files be encrypted while still maintaining a Secure Immutable MCUboot bootloader? Some sources say that encrypted images are not supported. 

It is possible to enable encrypted DFU. However, this is a feature we don't officially support in our SDK. It's therefore not tested or validated by us. Here are some other threads on this forum that you may find relevant:   Setting sysbuild encryption of DFU images ,  Using MCUBoot with nRF5340  

5. Do I need to modify MCUboot to provide read protection for the firmware? 

CONFIG_FPROTECT is enabled by default. You can confirm that is enabled by inspecting the generated .config file.

6. Can I get (4) and (5) with a single image slot? I don't want to waste space on a second image slot. 

Single slot DFU is only possible if you enable serial recovery support in MCUBoot, which allows DFU over UART or USB within the bootloader. Note that encrypted DFU is not supported in serial recovery mode. For FOTA, firmware images must be received while running the main application and therefore requires two slots.

Best regards,

Vidar

[Canadian_EE]

Is there a setting to close the debug port? Or would I have to modify the bootloader myself to close the debug port after a new image is written? 

[Vidar Berg]

See Enabling access port protection mechanism

[Canadian_EE]

Is this correct: "NRF_SECURE_APPROTECT_LOCK=y" to lock the debug port? 

Does this get put in the main prj.conf file? Do I also put it in the mcuboot.conf file? Can the lock be applied both during firmware operation and during bootloader operation? 

[Vidar Berg]

Yes. Lock action should be performed as early as possible, either in NSIB or MCUBoot depending on which first stage bootloader is used. HW AP-protect should be enabled as well.