How to use Hardware-based downgrade protection

Hello.

I am trying to follow Downgrade protection using MCUboot to enable Hardware-based downgrade protection.
However, an error occurred, and the software did not start. It is also from the initial flash, not after the update.

*** 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
E: Security counter update failed after image validation.
E: Unable to find bootable image

The "sysbuild.conf" is as follows.
It is the minimum configuration according to Exercise 5 – FOTA over Bluetooth Low Energy and Simultaneous updates for both cores of the nRF5340.
Naturally, if the last three lines related to downgrade protection are disabled, the software will start.

# STEP 2.1 Enable MCUboot
SB_CONFIG_BOOTLOADER_MCUBOOT=y

# STEP 6.3 - Configure project to use external flash for DFU
SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y

 # STEP 7.2 - Add b0n image
SB_CONFIG_SECURE_BOOT_NETCORE=y

# STEP 7.3 - Set up multiple partitions
SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES=2

# STEP 7.4 - Add support to netcore for DFU
SB_CONFIG_NETCORE_APP_UPDATE=y

# STEP 7.5 - Add support to mcuboot for updating
# two cores simultaneously
SB_CONFIG_MCUBOOT_NRF53_MULTI_IMAGE_UPDATE=y

# STEP 7.6 - Simultaneous FOTA does not support rollback
SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y

# Enable Hardware-based downgrade protection
SB_CONFIG_MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION=y
SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_SLOTS=24
SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE=1

Also, a similar issue was reported in another person's ticket.
However, even following the configuration there, the issue did not change.

Thanks for reading.

a.da

Parents
  • 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.

  • a.da said:
    I overlooked this. This PR also needs to be reflected, right?

    Yes.

    a.da said:
    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?

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

  • 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

Reply
  • 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

Children
Related