How to use Hardware-based downgrade protection

RE: How to use Hardware-based downgrade protection

a.da — Fri, 21 Mar 2025 07:21:48 GMT

Hi Sigurd,

You're right. I have written new questions here.

a.da

RE: How to use Hardware-based downgrade protection

Sigurd — Thu, 20 Mar 2025 11:21:39 GMT

Hi!

Amanda is out of office.

[quote user="a.da"]Thanks to your help, I was able to successfully update the Network Core.
The issue in the title has been resolved.[/quote]

Great!

[quote user="a.da"]However, I still have a few questions:[/quote]

Please open a new case for these new questions.

RE: How to use Hardware-based downgrade protection

a.da — Mon, 17 Mar 2025 04:41:39 GMT

Hi Amanda,

Thanks to your help, I was able to successfully update the Network Core.
The issue in the title has been resolved.

However, I still have a few questions:

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 ***

Kind regards,

a.da

RE: How to use Hardware-based downgrade protection

Amanda Hsieh — Fri, 14 Mar 2025 12:27:16 GMT

PR updated, should work now, please re-check.

RE: How to use Hardware-based downgrade protection

a.da — Tue, 11 Mar 2025 02:14:17 GMT

Hi Amanda,

By applying the differences in loader.c, the software has started successfully.

However, there are still some questions.
When I tried DFU, the Application Core ( Image 0 ) was updated, but the Network Core ( Image 1 ) was not.
It seems the transfer to the Secondary Slot was successful, but the image was reported as invalid.
The only change made to the transferred binary file was incrementing the SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE from 1 to 2.

[00:12:09.941,223] <inf> mcuboot_util: Image index: 0, Swap type: none
[00:12:09.941,711] <inf> mcuboot_util: Image index: 1, Swap type: none
[00:12:09.941,741] <err> mcumgr_img_grp: Failed to open flash area ID 1: -2
[00:12:10.242,584] <inf> mcuboot_util: Image index: 0, Swap type: none
[00:12:33.432,373] <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
E: Image in the secondary slot is not valid!
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: 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 ***

Is there anything I can do to help resolve this?

Kind regards,

a.da

RE: How to use Hardware-based downgrade protection

Amanda Hsieh — Mon, 10 Mar 2025 16:05:31 GMT

[quote user="a.da"]I overlooked this. This PR also needs to be reflected, right?[/quote]

Yes.

[quote user="a.da"]Also, I have some doubts about the changes.
It seems that dependencies necessary for enabling MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION have been added.
Even after reflecting these changes, MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION remained enabled.
What could be the problem?[/quote]

You can check the .config file under build\zephyr for the dependent configs.

RE: How to use Hardware-based downgrade protection

a.da — Mon, 10 Mar 2025 04:51:51 GMT

Hi Amanda, thanks for your reply.

Unfortunately, the issue has not changed.
I have reflected the changes written in the PR into nRF Connect SDK v2.9.0.
Since overwriting directly with the files attached to the PR results in a Build Error, I only applied the differences.
Do you know the steps to confirm that the issue has been fixed?

Also, I have some doubts about the changes.
It seems that dependencies necessary for enabling MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION have been added.
Even after reflecting these changes, MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION remained enabled.
What could be the problem?

a.da

Addendum:

I overlooked this. This PR also needs to be reflected, right?
I’ll check again.

RE: How to use Hardware-based downgrade protection

Amanda Hsieh — Fri, 07 Mar 2025 14:47:23 GMT

Hi,

It should get fixed by this PR: https://github.com/nrfconnect/sdk-nrf/pull/20787.

-Amanda H.

RE: How to use Hardware-based downgrade protection

Amanda Hsieh — Thu, 06 Mar 2025 23:35:09 GMT

Hi,

I am working on your case and will update it when I collect enough information.

Regards,
Amanda H.