Hardware-based downgrade protection in nRF5340

RE: Hardware-based downgrade protection in nRF5340

a.da — Wed, 07 May 2025 01:29:54 GMT

Hi Andreas,

[quote userid="107683" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/534076"]Monotonic counters should not work for network core appearently. It only supports for the first image, per https://github.com/nrfconnect/sdk-nrf/pull/20787's description[/quote]

Understood. Thank you for your support.

I will look into how to implement downgrade protection by referring to the resources.

Kind regards,

a.da

RE: Hardware-based downgrade protection in nRF5340

AHaug — Tue, 06 May 2025 09:31:05 GMT

Hello,

Apologies for not following up.

Monotonic counters should not work for network core appearently. It only supports for the first image, per https://github.com/nrfconnect/sdk-nrf/pull/20787's description

However Configuration on b0n image to read the Network Core version on SDK v2.9.0 refers to https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/tfm/tfm_psa_template/README.html and https://github.com/nrfconnect/sdk-nrf/blob/v2.9.0/samples/tfm/tfm_psa_template/sysbuild/mcuboot/boards/nrf5340dk_nrf5340_cpuapp.conf#L9 and https://github.com/nrfconnect/sdk-nrf/blob/v2.9.0/samples/tfm/tfm_psa_template/sysbuild/b0n/prj.conf#L31 which does enable downgrade prevention for the netcore. It looks like I've missed this previously.

Could you let me know if the latter resources are of any help?

Kind regards,
Andreas

RE: Hardware-based downgrade protection in nRF5340

a.da — Fri, 02 May 2025 05:08:24 GMT

Is there any follow-up?

RE: Hardware-based downgrade protection in nRF5340

a.da — Thu, 10 Apr 2025 05:43:35 GMT

Hi Andreas,

I have enabled downgrade protection on the SMP Server Sample with PR2269 applied.

There were no changes in the logs. Net Core was not enabled.

*** 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: 0x25f3c bytes
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot
*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***

[quote userid="107683" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/530999"]Do you use the b0n_CONIIG_PCD_READ_NETCORE_APP_VERSION configuration?[/quote]

As written here.

[quote userid="138526" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/529195"]./sysbuild/b0n.conf[/quote]

[quote userid="107683" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/530999"]Can you check if the two PRs are applied?[/quote]

PR20787 and PR402 were already applied when working on the originating ticket.

[quote userid="138526" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340"]This ticket was derived from another ticket.[/quote]

Have you tried the sample?

What do you want me to confirm?

Kind regards,

a.da

RE: Hardware-based downgrade protection in nRF5340

AHaug — Tue, 08 Apr 2025 10:02:20 GMT

Hi a.da,

While looking around for what could be wrong I found some PRs and suggestiosn

Use

PR
https://github.com/nrfconnect/sdk-nrf/pull/20787
https://github.com/nrfconnect/sdk-mcuboot/pull/402,

Together with https://github.com/nrfconnect/sdk-zephyr/pull/2269/files and the configuration (which you already use) added to sysbuild.conf

# 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

and build with this command:

west build -p -b nrf5340dk/nrf5340/cpuapp -- -DFILE_SUFFIX=nrf5340_bt -Dhci_ipc_CONFIG_FW_INFO_FIRMWARE_VERSION=2
-Db0n_CONFIG_PCD_READ_NETCORE_APP_VERSION=y

Do you use the b0n_CONIIG_PCD_READ_NETCORE_APP_VERSION configuration?

Can you check if the two PRs are applied?

Kind regards,
Andreas

RE: Hardware-based downgrade protection in nRF5340

a.da — Mon, 31 Mar 2025 23:43:20 GMT

Hi Andreas,

[quote userid="107683" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/529712"]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?[/quote]

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.

[quote userid="107683" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/529744"]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?[/quote]

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

Kind regards,

a.da

RE: Hardware-based downgrade protection in nRF5340

AHaug — Mon, 31 Mar 2025 10:26:04 GMT

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

RE: Hardware-based downgrade protection in nRF5340

AHaug — Mon, 31 Mar 2025 08:54:47 GMT

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

RE: Hardware-based downgrade protection in nRF5340

a.da — Sun, 30 Mar 2025 23:40:50 GMT

Hi Andreas,

[quote userid="107683" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/529551"]Are you able to compile it and perform a DFU with hw protection?[/quote]

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.

[quote userid="138526" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/529195"]

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

Result:

[/quote]

[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

RE: Hardware-based downgrade protection in nRF5340

AHaug — Fri, 28 Mar 2025 14:00:18 GMT

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

RE: Hardware-based downgrade protection in nRF5340

a.da — Fri, 28 Mar 2025 00:04:01 GMT

Hi Andreas,

[quote userid="107683" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/529237"]You also need to enable multi-image-update[/quote]

The following files seem to indicate that multi-image-update is enabled. Is that correct?

./build/mcuboot/zephyr/include/generated/zephyr/autoconf.h

Excerpt:

#define CONFIG_BOOT_UPGRADE_ONLY 1
#define CONFIG_BOOT_ENCRYPTION_SUPPORT 1
#define CONFIG_BOOT_MAX_IMG_SECTORS 256
#define CONFIG_BOOT_SHARE_BACKEND_DISABLED 1
#define CONFIG_BOOT_FIH_PROFILE_OFF 1
#define CONFIG_BOOT_USB_DFU_NO 1
#define CONFIG_MCUBOOT_LOG_LEVEL_DBG 1
#define CONFIG_MCUBOOT_LOG_LEVEL 4
#define CONFIG_MCUBOOT_LOG_THREAD_STACK_SIZE 768
#define CONFIG_UPDATEABLE_IMAGE_NUMBER 2
..
#define CONFIG_PCD_APP 1

Full:

devzone.nordicsemi.com/.../3107.autoconf.h

./partitions.yml

Full:

app:
  address: 0xc200
  end_address: 0xf8000
  region: flash_primary
  size: 0xebe00
external_flash:
  address: 0x12c000
  end_address: 0x800000
  region: external_flash
  size: 0x6d4000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    align:
      end: 0x1000
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  placement:
    align:
      start: 0x4000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0xf8000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xec000
  span: *id001
mcuboot_primary_1:
  address: 0x0
  device: nordic_ram_flash_controller
  end_address: 0x40000
  region: ram_flash
  size: 0x40000
mcuboot_primary_app:
  address: 0xc200
  end_address: 0xf8000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xebe00
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0xec000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0xec000
mcuboot_secondary_1:
  address: 0xec000
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x12c000
  region: external_flash
  size: 0x40000
otp:
  address: 0xff8380
  end_address: 0xff83fc
  region: otp
  size: 0x7c
pcd_sram:
  address: 0x20000000
  end_address: 0x20002000
  placement:
    after:
    - start
  region: sram_primary
  size: 0x2000
provision:
  address: 0xff8100
  end_address: 0xff8380
  region: otp
  size: 0x280
ram_flash:
  address: 0x40000
  end_address: 0x40000
  region: ram_flash
  size: 0x0
rpmsg_nrf53_sram:
  address: 0x20070000
  end_address: 0x20080000
  placement:
    before:
    - end
  region: sram_primary
  size: 0x10000
settings_storage:
  address: 0xf8000
  end_address: 0x100000
  placement:
    align:
      start: 0x4000
    before:
    - end
  region: flash_primary
  size: 0x8000
sram_primary:
  address: 0x20002000
  end_address: 0x20070000
  region: sram_primary
  size: 0x6e000

Is there anything else that needs to be confirmed?

Kind regards,

a.da

RE: Hardware-based downgrade protection in nRF5340

AHaug — Thu, 27 Mar 2025 09:30:04 GMT

Hi a.da,

You also need to enable multi-image-update, i.e https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf53/simultaneous_multi_image_dfu_nrf5340.html, so that https://github.com/nrfconnect/sdk-mcuboot/blob/148712e7b4618aadbedd04e8d3ce5c3847d3be4f/boot/bootutil/src/loader.c#L1063 can recognize that it should compare the netcore image as well.

If you still see that it doesn't work when enabling this, then there might be a bug in the implementation. Let me know and I'll file a report if that's the case

Kind regards,
Andreas

RE: Hardware-based downgrade protection in nRF5340

a.da — Thu, 27 Mar 2025 06:19:29 GMT

Hi Andreas,

[quote userid="107683" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/529086"]Does this still resonate with your understanding?[/quote]

Sorry, I’m a bit confused. Meaning, which two numbers should I make the same?

This is configurations and result I tried.
I made the values of SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE and CONFIG_FW_INFO_FIRMWARE_VERSION the same.
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 ***

./sysbuild.conf

# 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 using MCUboot
SB_CONFIG_MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION=y
SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_SLOTS=4
SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE=2

./prj.conf

CONFIG_NCS_SAMPLES_DEFAULTS=y

# Deferred logging helps improve LPN power consumption
# when friendship is established.
CONFIG_LOG_MODE_DEFERRED=y

# General configuration
CONFIG_NCS_APPLICATION_BOOT_BANNER_STRING="Mesh Light Fixture"
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
CONFIG_FLASH=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_NVS_LOOKUP_CACHE=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_NVS_NAME_CACHE=y
CONFIG_HWINFO=y
CONFIG_DK_LIBRARY=y
CONFIG_PWM=y
CONFIG_PM_SINGLE_IMAGE=y
CONFIG_PM_PARTITION_SIZE_SETTINGS_STORAGE=0x8000
CONFIG_SOC_FLASH_NRF_PARTIAL_ERASE=y

# Bluetooth configuration
CONFIG_BT=y
CONFIG_BT_DEVICE_NAME="Mesh Light Fixture"
CONFIG_BT_L2CAP_TX_BUF_COUNT=8
CONFIG_BT_OBSERVER=y
CONFIG_BT_PERIPHERAL=y

# Disable unused Bluetooth features
CONFIG_BT_CTLR_LE_ENC=n
CONFIG_BT_PHY_UPDATE=n
CONFIG_BT_CTLR_CHAN_SEL_2=n
CONFIG_BT_CTLR_MIN_USED_CHAN=n
CONFIG_BT_CTLR_PRIVACY=n

# Bluetooth Mesh configuration
CONFIG_BT_MESH=y
CONFIG_BT_MESH_RELAY=y
CONFIG_BT_MESH_FRIEND=y
CONFIG_BT_MESH_TX_SEG_MAX=10
CONFIG_BT_MESH_PB_GATT=y
CONFIG_BT_MESH_PROXY_USE_DEVICE_NAME=y
CONFIG_BT_MESH_GATT_PROXY=y
CONFIG_BT_MESH_ADV_EXT_GATT_SEPARATE=y
CONFIG_BT_MESH_DK_PROV=y
CONFIG_BT_MESH_NLC_PERF_CONF=y
CONFIG_BT_MESH_NLC_PERF_LIGHTNESS_CTRL=y
CONFIG_BT_MESH_MODEL_EXTENSIONS=y
CONFIG_BT_MESH_MODEL_EXTENSION_LIST_SIZE=18
# Enabling BT_MESH_NLC_PERF_CONF enables support for 3 application keys by
# default. Therefore, allow up to 3 application key bindings per model instance.
CONFIG_BT_MESH_MODEL_KEY_COUNT=3

# Bluetooth Mesh models
CONFIG_BT_MESH_LIGHT_CTRL_SRV=y
CONFIG_BT_MESH_LIGHT_CTRL_SRV_TIME_ON=3
CONFIG_BT_MESH_LIGHT_CTRL_SRV_TIME_PROLONG=3
CONFIG_BT_MESH_LIGHT_CTRL_SRV_RESUME_DELAY=30
CONFIG_BT_MESH_SCENE_SRV=y
CONFIG_BT_MESH_SENSOR_SRV=y

# STEP 2.2 - Enable FOTA over Bluetooth LE
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

# Enable updates for the network core
CONFIG_NRF53_UPGRADE_NETWORK_CORE=y

./sysbuild/mcuboot.conf

# STEP 6.2 - MCUboot should use external flash
CONFIG_NORDIC_QSPI_NOR=y
CONFIG_BOOT_MAX_IMG_SECTORS=256

# Enable PCD command to read network core application version
CONFIG_FW_INFO=y
CONFIG_PCD_READ_NETCORE_APP_VERSION=y

# Enable Debug Log
CONFIG_MCUBOOT_LOG_LEVEL_DBG=y

./sysbuild/b0n.conf

# Enable PCD command to read network core application version
CONFIG_PCD_READ_NETCORE_APP_VERSION=y

./sysbuild/ipc_radio/prj.conf

CONFIG_HEAP_MEM_POOL_SIZE=8192
CONFIG_MAIN_STACK_SIZE=2048
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

CONFIG_MBOX=y
CONFIG_IPC_SERVICE=y

CONFIG_BT=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_MAX_CONN=16

# Copy controller configuration from prj.conf
CONFIG_BT_CTLR_LE_ENC=n
CONFIG_BT_CTLR_CHAN_SEL_2=n
CONFIG_BT_CTLR_MIN_USED_CHAN=n
CONFIG_BT_CTLR_PRIVACY=n

# Enables the extended advertising API support and the necessary amount of advertising sets
# in the Bluetooth controller on the network core required by the Bluetooth Mesh.
CONFIG_BT_EXT_ADV=y
CONFIG_BT_EXT_ADV_MAX_ADV_SET=5

CONFIG_IPC_RADIO_BT=y
CONFIG_IPC_RADIO_BT_HCI_IPC=y

# Step 9.2 - Enable logs in netcore so we can verify the update
CONFIG_SERIAL=y
CONFIG_UART_CONSOLE=y
CONFIG_LOG=y

# Enable version number of the firmware
CONFIG_FW_INFO_FIRMWARE_VERSION=2

# Enable logs in netcore
CONFIG_IPC_RADIO_LOG_LEVEL_WRN=y

Kind regards,

a.da

RE: Hardware-based downgrade protection in nRF5340

AHaug — Wed, 26 Mar 2025 14:00:26 GMT

[quote user="a.da"]Thank you for your detailed explanation. I also apologize for my inadequate explanation.[/quote][quote user="a.da"]Yes, I understand how to enable Software-based downgrade protection.[/quote]

No worries, happy to discuss it further

[quote user="a.da"]

Do you mean to set it up as follows?

App Core ( ./sysbuild.conf )

SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_SLOTS
SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE

Net Core ( ./sysbuild/<netcore_name>/prj.conf )

CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_SLOTS
CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE

[/quote]

I did a revisit to my investigation yesterday, and I think my conclusion has changed somewhat. I was under the impression that we supported individual app and netcore versioning and downgrade protection, but it looks to be as you said initially, i.e this:

[quote user="a.da"]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.[/quote]

https://github.com/nrfconnect/sdk-mcuboot/blob/148712e7b4618aadbedd04e8d3ce5c3847d3be4f/boot/bootutil/src/loader.c#L1063 shows that downgrade protection for netcore is only valid in a multi image update for the nrf5340, i.e a simultaneous update.

Conclusion:

These configurations works for both cores and must be maintained similarly. App and netcore versions must match to enable downgrade protection on both cores since it requires simultaneous multi-image update to work.

SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_SLOTS
SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE

Does this still resonate with your understanding?

Kind regards,
Andreas

RE: Hardware-based downgrade protection in nRF5340

a.da — Wed, 26 Mar 2025 07:24:30 GMT

Hi Andreas,

Thank you for your detailed explanation. I also apologize for my inadequate explanation.

[quote userid="107683" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/528821"]It implies it but it does not necessarily enable it as you can have firmware versions without enabling downgrade protection.[/quote]

Yes, I understand how to enable Software-based downgrade protection.

[quote userid="107683" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/528821"]To my understanding, this means you can have different counters for the different slots, and if you intend to only upgrade the app core you need to increment the counter for the image corresponding to the app core, and respectively the same for the counter for the netcore when you upgrade the firmware in the netcore.[/quote]

Do you mean to set it up as follows?

App Core ( ./sysbuild.conf )

SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_SLOTS
SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE

Net Core ( ./sysbuild/<netcore_name>/prj.conf )

CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_SLOTS
CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE

[quote userid="107683" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/528821"]I've not seen anything indicating that you need to do this, since you can have separate counters for both.[/quote]

The term 'version' was not appropriate.
I understand that we need to prevent inconsistencies in the configuration (Project / Source Code) in which the software was built.

Kind regards,

a.da

RE: Hardware-based downgrade protection in nRF5340

AHaug — Tue, 25 Mar 2025 11:41:13 GMT

Hi,

[quote user="a.da"]I have already referred to that page.[/quote]

Great!

[quote user="a.da"]The need to change 'CONFIG_FW_INFO_FIRMWARE_VERSION' means that Net Core has Software-based downgrade protection enabled, right?[/quote]

It implies it but it does not necessarily enable it as you can have firmware versions without enabling downgrade protection.

For software-based downgrade protection you need CONFIG_MCUBOOT_DOWNGRADE_PREVENTION enabled for the mcuboot image (i.e within sysbuild/mcuboot.conf or sysbuild/mcuboot/mcuboot.conf) and SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y enabled in sysbuild.conf for "CONFIG_MCUBOOT_BOOTLOADER_MODE_OVERWRITE_ONLY (see Sysbuild forced options)

"MCUboot has been configured to just overwrite primary slot

MCUboot will take contents of secondary slot of an image and will overwrite primary slot with it. In this mode it is not possible to revert back to previous version as it is not stored in the secondary slot. This mode supports MCUBOOT_BOOTLOADER_NO_DOWNGRADE which means that the overwrite will not happen unless the version of secondary slot is higher than the version in primary slot."

[quote user="a.da"]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?[/quote]

CONFIG_MCUBOOT_HARDWARE_DOWNGRADE_PREVENTION enables Downgrade prevention using hardware security counters meaning you can use the counter values from

SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_SLOTS, i.e CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_SLOTS
SB_CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE i.e CONFIG_MCUBOOT_HW_DOWNGRADE_PREVENTION_COUNTER_VALUE

To my understanding, this means you can have different counters for the different slots, and if you intend to only upgrade the app core you need to increment the counter for the image corresponding to the app core, and respectively the same for the counter for the netcore when you upgrade the firmware in the netcore.

Furthermore in https://github.com/nrfconnect/sdk-mcuboot/blob/148712e7b4618aadbedd04e8d3ce5c3847d3be4f/boot/bootutil/src/loader.c#L1063 you can see pcd_version_cmp_net() which checks the netcore version in MCUboot, i.e MCUBoot checks the versioning for you and it checks it different than the application version number, i.e through boot_version_cmp (L1066 and L:1068).

[quote user="a.da"]I believe that the combination of App Core and Net Core versions must always match.[/quote]

I've not seen anything indicating that you need to do this, since you can have separate counters for both. I know that you can have different firmware versioning for appcore and netcore based on https://github.com/nrfconnect/sdk-mcuboot/blob/148712e7b4618aadbedd04e8d3ce5c3847d3be4f/boot/bootutil/src/loader.c#L1063

Kind regards,
Andreas

RE: Hardware-based downgrade protection in nRF5340

a.da — Mon, 24 Mar 2025 00:53:26 GMT

Hi Andreas, thanks for your reply.

[quote userid="107683" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/528425"]I've picked up your case and will be looking into it early next week.[/quote]

I appreciate your assistance.

[quote userid="107683" url="~/f/nordic-q-a/120026/hardware-based-downgrade-protection-in-nrf5340/528425"]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?[/quote]

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

RE: Hardware-based downgrade protection in nRF5340

AHaug — Fri, 21 Mar 2025 14:10:49 GMT

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