Hardware-based downgrade protection in nRF5340

[a.da]

Hello.

This ticket was derived from another ticket.

I have a few questions about hardware-based downgrade protection.

• About the Downgrade Protection of the Network Core
  Even with Downgrade Protection enabled, the Network Core is still downgradeable.
  However, version mismatches between the App Core and the Network Core should be avoided.
  If you have any ideas on how to resolve this, please let me know.
• About the monotonic counter
  Is there a way to retrieve the current value?
  I am assuming it will be displayed on a PC serial terminal or a smartphone app.
• About Image Swap
  It seems that when the update count reaches the value of SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_SLOTS, the Image Swap of the App Core is performed every time the software is rebooted.
  Is this the expected behavior?

The logs during the update and reboot are as follows:

monotonic counter < SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_SLOTS

Update

[00:00:18.749,969] <err> mcumgr_img_grp: Failed to open flash area ID 1: -2
[00:00:19.052,307] <inf> mcuboot_util: Image index: 0, Swap type: none
[00:00:41.610,382] <inf> mcuboot_util: Image index: 1, Swap type: none
*** Booting MCUboot v2.1.0-dev-12e5ee106034 ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
I: Starting bootloader
I: Image index: 0, Swap type: perm
I: Image index: 1, Swap type: perm
I: Image 0 upgrade secondary slot -> primary slot
I: Erasing the primary slot
I: Image 0 copying the secondary slot to the primary slot: 0x44784 bytes
D: writing magic; fa_id=4 off=0xebff0 (0xf7ff0)
D: erasing secondary header
D: erasing secondary trailer
I: Image 1 upgrade secondary slot -> primary slot
I: Erasing the primary slot
I: Image 1 copying the secondary slot to the primary slot: 0x2a3c0 bytes
D: writing magic; fa_id=1 off=0x3fff0 (0x3fff0)
D: erasing secondary header
D: erasing secondary trailer
I: Bootloader chainload address offset: 0xc000
*** Booting Mesh Light Fixture v2.9.0-d54b9798c66e ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***

Reboot

*** Booting MCUboot v2.1.0-dev-12e5ee106034 ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
I: Starting bootloader
I: Image index: 0, Swap type: none
I: Image index: 1, Swap type: none
I: Bootloader chainload address offset: 0xc000
*** Booting Mesh Light Fixture v2.9.0-d54b9798c66e ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***

monotonic counter = SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_SLOTS

Update

[00:00:30.237,457] <err> mcumgr_img_grp: Failed to open flash area ID 1: -2
[00:00:30.538,299] <inf> mcuboot_util: Image index: 0, Swap type: none
[00:00:53.067,932] <inf> mcuboot_util: Image index: 1, Swap type: none
*** Booting MCUboot v2.1.0-dev-12e5ee106034 ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
I: Starting bootloader
I: Image index: 0, Swap type: perm
I: Image index: 1, Swap type: perm
I: Image 0 upgrade secondary slot -> primary slot
I: Erasing the primary slot
I: Image 0 copying the secondary slot to the primary slot: 0x44784 bytes
D: writing magic; fa_id=4 off=0xebff0 (0xf7ff0)
E: Security counter update failed after image upgrade.
I: Image 1 upgrade secondary slot -> primary slot
I: Erasing the primary slot
I: Image 1 copying the secondary slot to the primary slot: 0x2a3c0 bytes
D: writing magic; fa_id=1 off=0x3fff0 (0x3fff0)
D: erasing secondary header
D: erasing secondary trailer
I: Bootloader chainload address offset: 0xc000
*** Booting Mesh Light Fixture v2.9.0-d54b9798c66e ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***

Reboot

*** Booting MCUboot v2.1.0-dev-12e5ee106034 ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
I: Starting bootloader
I: Image index: 0, Swap type: perm
I: Image index: 1, Swap type: none
I: Image 0 upgrade secondary slot -> primary slot
I: Erasing the primary slot
I: Image 0 copying the secondary slot to the primary slot: 0x44784 bytes
D: writing magic; fa_id=4 off=0xebff0 (0xf7ff0)
E: Security counter update failed after image upgrade.
I: Bootloader chainload address offset: 0xc000
*** Booting Mesh Light Fixture v2.9.0-d54b9798c66e ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***

Thanks for reading.

a.da

[AHaug]

Hi a.da

I've picked up your case and will be looking into it early next week. As a starter I was hoping you could have a look at  CONFIG_MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION in NRF5340 multi update and see if the solution in this case and/or the case this one refers to is of any help in resolve the issues you're observing with the netcore downgrade protection not being enabled?

Kind regards,
Andreas 

[a.da]

Hi Andreas, thanks for your reply.

AHaug said:

I've picked up your case and will be looking into it early next week.

I appreciate your assistance.

AHaug said:

As a starter I was hoping you could have a look at  CONFIG_MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION in NRF5340 multi update and see if the solution in this case and/or the case this one refers to is of any help in resolve the issues you're observing with the netcore downgrade protection not being enabled?

I have already referred to that page.
The need to change 'CONFIG_FW_INFO_FIRMWARE_VERSION' means that Net Core has Software-based downgrade protection enabled, right?
By simply changing 'SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE', can we enable Hardware-based downgrade protection on both App Core and Net Core?
I believe that the combination of App Core and Net Core versions must always match.
Therefore, if we want to implement downgrade protection, I think it needs to be enabled on both App Core and Net Core.
Also, it is preferable to have a single piece of information that manages the combination.

Kind regards,

a.da

[AHaug]

Hi,

This looks to be correct according to the multi_image dfu guide, and is what I would've expected to see in my generated .config atleast. Are you able to compile it and perform a DFU with hw protection?

Kind regards,
Andreas

[a.da]

Hi Andreas,

AHaug said:

Are you able to compile it and perform a DFU with hw protection?

It seems that hw protection was enabled for the App Core, but not for the Net Core.

The result is the same as the one I posted earlier.

a.da said:

After upgrading to '2' via the nRF Device Manager App, I tried to downgrade to '1'.
Net Core's Downgrade Protection has failed.

Result:

[00:00:37.332,916] <inf> mcuboot_util: Image index: 0, Swap type: none
[00:00:59.952,514] <inf> mcuboot_util: Image index: 1, Swap type: none
*** Booting MCUboot v2.1.0-dev-12e5ee106034 ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
I: Starting bootloader
I: Image index: 0, Swap type: perm
E: Image in the secondary slot is not valid!
I: Image index: 1, Swap type: perm
I: Image 1 upgrade secondary slot -> primary slot
I: Erasing the primary slot
I: Image 1 copying the secondary slot to the primary slot: 0x2a3c0 bytes
D: writing magic; fa_id=1 off=0x3fff0 (0x3fff0)
D: erasing secondary header
D: erasing secondary trailer
I: Bootloader chainload address offset: 0xc000
*** Booting Mesh Light Fixture v2.9.0-d54b9798c66e ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***

Kind regards,

a.da

[AHaug]

Hi,

As a sanity check, could you go through the 19 lines in the device log and tell me if I see the same thing as you

6: you enter the bootloader and load the image to secondary. It has index 0 and swap type perm. You get an error that states "the new image is not valid", i.e something is detected and it should abort the update here. Nonetheless, it keeps on running and you update the image in the secondary slot to the primary slot in L 12. This is what you mean when you say the protection has failed for the netcore?

If my understanding matches your observation I'll escalate it as a bug.

Kind regards,
Andreas

[AHaug]

Another question, what file are you using for the update? A multi-image update implies that you update both app and netcore simultaneous. Is the logs from your update with or without simultaneous update?

Kind regards,
Andreas

[a.da]

Hi Andreas,

AHaug said:

6: you enter the bootloader and load the image to secondary. It has index 0 and swap type perm. You get an error that states "the new image is not valid", i.e something is detected and it should abort the update here. Nonetheless, it keeps on running and you update the image in the secondary slot to the primary slot in L 12. This is what you mean when you say the protection has failed for the netcore?

Yes, that's correct.
I understand that lines 7 to 8 indicate an error in the update of the App Core.
On the other hand, lines 9 to 12 seem to indicate the successful update of the Net Core.
Therefore, it seems that the protection for the App Core is enabled, while the protection for the Net Core is not.

However, I do not know the correct log that would be output if both protections are enabled.
I haven't been able to find an example to reference.

AHaug said:

Another question, what file are you using for the update? A multi-image update implies that you update both app and netcore simultaneous. Is the logs from your update with or without simultaneous update?

dfu_application.zip
It includes "app.signed.bin", "ipc_radio.bin", and "manifest.json".

Kind regards,

a.da