Debug Port Disabled After Flashing TF-M Provisioning Image on nRF9151DK: Is This Intentional?

RE: Debug Port Disabled After Flashing TF-M Provisioning Image on nRF9151DK: Is This Intentional?

Hung Bui — Wed, 25 Sep 2024 11:03:03 GMT

Hi Vytautas,
I would consider this as a feature not a bug. The documentation should be improved though. You can leave the ticket as is.

RE: Debug Port Disabled After Flashing TF-M Provisioning Image on nRF9151DK: Is This Intentional?

vytautas — Mon, 23 Sep 2024 12:41:39 GMT

The ticket can be closed, though I am not sure which answer should be 'verified'.

RE: Debug Port Disabled After Flashing TF-M Provisioning Image on nRF9151DK: Is This Intentional?

Hung Bui — Fri, 20 Sep 2024 14:15:32 GMT

I agree, the documentation should mention that the sample also demonstrate blocking debug port on the app core .

RE: Debug Port Disabled After Flashing TF-M Provisioning Image on nRF9151DK: Is This Intentional?

vytautas — Fri, 20 Sep 2024 13:57:34 GMT

The way it is now is acceptable to me.

For debugging, we can just use a patched/modified file.

I was just outlying everything for anyone who stumbles across this ticket.

Though I do think it should be added to the README.md that debug port will be disabled

RE: Debug Port Disabled After Flashing TF-M Provisioning Image on nRF9151DK: Is This Intentional?

Hung Bui — Fri, 20 Sep 2024 13:49:46 GMT

Hi Vytautas,

If you take a look at this: https://docs.nordicsemi.com/bundle/ps_nrf9151/page/dif.html#ariaid-title3

You can find that the Debug/Access port is protected by both hardware and software. The UICR.APPROTECT is the Hardware protection. It's not just for indication.

To be honest I'm not too familiar with TFM and PSA, but my point of view is that after you run provisioning image and having identity key stored on UICR, you MUST have disable port locked. From security point of view, this is a MUST. I know that for developing you still want to be able to access debug port and want that we provide an option/configuration to disable this feature.

But as security sample I don't think it's a good idea. This create a chance that product getting out on the market with this backdoor still open because the developer forgot to remove the DEBUG option. Trust me, this story is really not uncommon.

After the UICR.APPROTECT block the debug port access, the only way to change this value is to erase the UICR and the only way to erase the UICR is to do an Eraseall (if it's still not blocked).

RE: Debug Port Disabled After Flashing TF-M Provisioning Image on nRF9151DK: Is This Intentional?

vytautas — Thu, 19 Sep 2024 14:34:27 GMT

On the SiP it says "NRF9151 LACA A0 2422AAAC002TKFE"

I managed to get debugging to work. I originally thought that UICR by itself isn't going to disable the debug port and was set only to indicate the debugging needs to be disabled.

To enable debugging, apply the following patch:

diff --git nrf/modules/trusted-firmware-m/tfm_boards/common/nrf_provisioning.c nrf/modules/trusted-firmware-m/tfm_boards/common/nrf_provisioning.c
index 4ce7792e1..cd8c9e782 100644
--- nrf/modules/trusted-firmware-m/tfm_boards/common/nrf_provisioning.c
+++ nrf/modules/trusted-firmware-m/tfm_boards/common/nrf_provisioning.c
@@ -29,7 +29,7 @@ static enum tfm_plat_err_t disable_debugging(void)

        if (approt_writable) {
                nrfx_nvmc_word_write((uint32_t)&NRF_UICR_S->APPROTECT,
-                                    UICR_APPROTECT_PALL_Protected);
+                                    UICR_APPROTECT_PALL_HwUnprotected);
                nrfx_nvmc_word_write((uint32_t)&NRF_UICR_S->SECUREAPPROTECT,
                                     UICR_SECUREAPPROTECT_PALL_Protected);
        } else {

(You might also need to apply the workaround in the errata. In my case it wasn't necessary)

The default behavior for the TF-M implementation for NRF is to disable the debugger.

There doesn't seem to be a way to prevent this without modifying the code.

(Perhaps something to look into for Nordic?)

See nrf/modules/trusted-firmware-m/tfm_boards/common/nrf_provisioning.c:

static enum tfm_plat_err_t disable_debugging(void)
{
	/* Configure the UICR such that upon the next reset, APPROTECT will be enabled */
	bool approt_writable;

	approt_writable = nrfx_nvmc_word_writable_check((uint32_t)&NRF_UICR_S->APPROTECT,
							UICR_APPROTECT_PALL_Protected);
	approt_writable &= nrfx_nvmc_word_writable_check((uint32_t)&NRF_UICR_S->SECUREAPPROTECT,
							 UICR_SECUREAPPROTECT_PALL_Protected);

	if (approt_writable) {
		nrfx_nvmc_word_write((uint32_t)&NRF_UICR_S->APPROTECT,
				     UICR_APPROTECT_PALL_HwUnprotected);
		nrfx_nvmc_word_write((uint32_t)&NRF_UICR_S->SECUREAPPROTECT,
				     UICR_SECUREAPPROTECT_PALL_Protected);
	} else {
		return TFM_PLAT_ERR_SYSTEM_ERR;
	}

	return TFM_PLAT_ERR_SUCCESS;
}

If NRF_APPROTECT_USER_HANDLING is set, you will likely need to modify the UICR register yourself to unlock the debugger. Though I haven't tried this out yet... though isn't UICR supposed to be locked and inaccessible?

RE: Debug Port Disabled After Flashing TF-M Provisioning Image on nRF9151DK: Is This Intentional?

Hung Bui — Thu, 19 Sep 2024 10:36:57 GMT

Hi Vytautas,
Do you have any other DK that you can test for example the nRF9160DK ?
I got a tip from a coworker that this behavior can be related to this errata:
https://docs.nordicsemi.com/bundle/errata_nRF9151_Rev1/page/ERR/nRF9151/Rev1/latest/anomaly_151_36.html#anomaly_151_36

You can also try the workaround in the errata to see if it help solving the issue.