Why to enable APPROTECT for nRF5430 net core

[chiba]

NCS 2.6.0
nRF5340
project /ncs/v2.6.0/nrf/samples/matter/lock

I want to enable APPROTECT on both app core and net core core.
I want to enable it in firmware without UICR.

I could do this by adding CONFIG_NRF_APPROTECT_LOCK=y to my_project/child_image/mcuboot/prj.conf.

This setting is only on the app core side, but why is APPROTECT enabled on the net core side as well?

What are Nordic's recommendations?

nRF-Programmer LOG

INFO Using nrfutil device to communicate with target via JLink
INFO JLink OB firmware version J-Link OB-nRF5340-NordicSemi compiled Jun 25 2024 17:06:45
INFO Device family NRF53_FAMILY
INFO Device version NRF5340_xxAA_ENGD
INFO Board version PCA10095
DEBUG Sending event "programmer: device selected"
DEBUG Sending event "programmer: running nrfutil device"
DEBUG Sending event "programmer: running nrfutil device"
INFO Update files regions according to Application core
INFO Parse memory regions for file
INFO Update files regions according to Network core
INFO Parse memory regions for file
DEBUG Sending event "programmer: running nrfutil device"
INFO Reading readback protection status for Application core
INFO Reading readback protection status for Application core 0%
INFO Reading readback protection status for Application core 100%
INFO Application core protection status 'NRFDL_PROTECTION_STATUS_ALL'
INFO Reading readback protection status for Application core completed
INFO Reading readback protection status for Network core
INFO Reading readback protection status for Network core 0%
INFO Reading readback protection status for Network core 100%
INFO Network core protection status 'NRFDL_PROTECTION_STATUS_NONE' <--------------------- non protect
INFO Reading readback protection status for Network core completed
INFO Skipping reading core Application information as it is protected.
DEBUG Sending event "programmer: running nrfutil device"
DEBUG Sending event "programmer: running nrfutil device"
DEBUG Sending event "programmer: running nrfutil device"
INFO Loading core information for Network core
INFO Update files regions according to Application core
INFO Parse memory regions for file
INFO Update files regions according to Network core
INFO Parse memory regions for file
INFO Loading core information for Network core 0%
INFO Loading core information for Network core 100%
INFO Loading core information for Network core completed
INFO Update files regions according to Application core
INFO Parse memory regions for file
INFO Update files regions according to Network core
INFO Parse memory regions for file
DEBUG Sending event "programmer: running nrfutil device"
DEBUG Sending event "programmer: running nrfutil device"
DEBUG Sending event "programmer: running nrfutil device"
INFO Reading readback protection status for Application core
INFO Reading readback protection status for Application core 0%
INFO Reading readback protection status for Application core 100%
INFO Application core protection status 'NRFDL_PROTECTION_STATUS_ALL'
INFO Reading readback protection status for Application core completed
INFO Reading readback protection status for Network core
INFO Reading readback protection status for Network core 0%
INFO Reading readback protection status for Network core 100%
INFO Network core protection status 'NRFDL_PROTECTION_STATUS_ALL' <--------------------- change?
INFO Reading readback protection status for Network core completed
INFO Device is loaded and ready for further operation

[Einar Thorsrud]

Hi,

I could do this by adding CONFIG_NRF_APPROTECT_LOCK=y to my_project/child_image/mcuboot/prj.conf.

I recomment that you add this config for the network core as well. See Enabling access port protection mechanism for details on this from a firmware perspective (the AP protect mecahnism itself is documented in the product specification of the device).

This setting is only on the app core side, but why is APPROTECT enabled on the net core side as well?

I see the same on my end, where debugging is blocked for the network core after writing to APPROTECT.LOCK on the application core. I am checking internally regarding this and will come back to you.

[chiba]

Thank you for your reply.

I understand that the settings are required on the net core as well.

We look forward to further reports.

[SamJenkins2010]

Any update on this?
I'm seeing even when I update the app core protection at run-time to:
  NRF_UICR_S->APPROTECT           = 0x00000000
  NRF_UICR_S->SECUREAPPROTECT     = 0x00000000
  NRF_CTRLAP_S->APPROTECT.DISABLE = 0x00000000

the net core continues to show that it is "unprotected":
  NRF_UICR_NS->APPROTECT           = 0x50FA50FA
  NRF_CTRLAP_NS->APPROTECT.DISABLE = 0x50FA50FA

So either the app core has to be able to write the the net core UICR space or there has to be an IPC message sent over to the net core to instruct it to enable the debug port protection.

[Einar Thorsrud]

Hi,

I am sorry, I forgot to update. It is by design that it behaves like this (debugging of net core is blocked when AP protect is enabled on the app core).

You can write to the UICR of the net core while the APP core is un-protected, before protecting the app core. You can (and should) also add CONFIG_NRF_APPROTECT_LOCK=y for both the app and net core application, which will ensure that the debug interface is locked (this does not affect the UICR value, but is used during startup and prevents un-locking - see nrf53_handle_approtect() for reference, as well as the documentation here).

[SamJenkins2010]

Thanks for the quick reply.

Usage of the CONFIG_* options and building the firmware with the DAP protected is straightforward and I understand that method. I am trying to enable the DAP protection at a particular stage in the manufacturing/production process. So I don't want to build the firmware image with it disabled with the initial execution of the firmware using the hard coded execution path. This is where the complication comes in (i.e., making the transition from unprotected to protected at run-time based on an external command/stimulus). Additionally, there is no longer a debug interface, so things that could normally be done with a debugger and the DAP to one or the other cores via direct external modification, is unavailable at this stage.

I have confirmed that nrfjprog does not seem to be able to connect to and read through the NET core after I have protected the APP core. My concern was that maybe there is something wrong with the nrfjprog communication that was preventing access, and someone with know-how that was determined and persistent could still gain access to the device through the NET core DAP. Therefore, I was considering changing the NET core to read the APP core NRF_CTRLAP_S->APPROTECT.DISABLE (0x50006544) and write to its own disable NRF_CTRLAP_NS->APPROTECT.DISABLE the value read. This would essentially bypass the NET core's NRF_UICR_NS->APPROTECT setting and rely on the APP core's setting.

[Einar Thorsrud]

Hi,

SamJenkins2010 said:

I am trying to enable the DAP protection at a particular stage in the manufacturing/production process.

I see. I am not sure I undrstand the problem, though. Can you not enable AP protect on the UICR for the netcore before you enable it on the app core? Also, and importantly: note that changes to the UICR only takes effect after a reset, and that includes locking down the debug interface if it was initially open.

SamJenkins2010 said:

I have confirmed that nrfjprog does not seem to be able to connect to and read through the NET core after I have protected the APP core.

Yes. But note that it is possible to do an erase all operation on the application core, which also allow syou to disable AP protect on that core, and after this, the network core would still be accessible if AP protect is not explicitly enabled for the network core. So you must enable protection (or rather not disable it) for each core where you need it.