TF-M Isolation Level is 1 with Profile Large

RE: TF-M Isolation Level is 1 with Profile Large

Amanda Hsieh — Thu, 04 Apr 2024 18:38:49 GMT

Hi,

There is no public repository for sdk-modules to pull requests, so I will forward it to the team. Thanks for the nice sharing.

-Amanda H.

RE: TF-M Isolation Level is 1 with Profile Large

jeremyherbert — Thu, 04 Apr 2024 03:50:23 GMT

I was trying to do the same thing but accessing OTP in NS, and I ended up implementing it this way. Here is my patch (for ncs v2.5.2)

diff --git a/modules/tfm/tfm/boards/services/include/tfm_read_ranges.h b/modules/tfm/tfm/boards/services/include/tfm_read_ranges.h
index 2f95b4eb7..56b366211 100644
--- a/modules/tfm/tfm/boards/services/include/tfm_read_ranges.h
+++ b/modules/tfm/tfm/boards/services/include/tfm_read_ranges.h
@@ -41,6 +41,15 @@
 
 #endif /* NRF_FICR_S_BASE */
 
+#ifdef NRF_UICR_S_BASE
+
+#define UICR_BASE              NRF_UICR_S_BASE
+
+#define UICR_OTP_ADDR          (UICR_BASE + offsetof(NRF_UICR_Type, OTP))
+#define UICR_OTP_SIZE          (sizeof(((NRF_UICR_Type *)0)->OTP))
+
+#endif /* NRF_UICR_S_BASE */
+
 static const struct tfm_read_service_range ranges[] = {
 #ifdef PM_MCUBOOT_ADDRESS
        /* Allow reads of mcuboot metadata */
@@ -61,6 +70,9 @@ static const struct tfm_read_service_range ranges[] = {
 #if defined(FICR_SIPINFO_ADDR)
        { .start = FICR_SIPINFO_ADDR, .size = FICR_SIPINFO_SIZE },
 #endif
+#if defined(UICR_OTP_ADDR)
+       { .start = UICR_OTP_ADDR, .size = UICR_OTP_SIZE },
+#endif
 };
 
 #endif /* TFM_READ_RANGES_H__ */

I have no idea if Nordic will support this in their SDK (perhaps hidden behind a Kconfig option?). And I'm not sure if they will accept a PR from a non-employee.

RE: TF-M Isolation Level is 1 with Profile Large

Amanda Hsieh — Tue, 02 Apr 2024 14:39:33 GMT

Hi,

You need a custom memory read service implemented in Platform Root of Trust to read UICR in Isolation 2 (and non-supported level 3). ARoTs don't have access to UICRs. Level 1 isolation makes every service look like it is in Platform RoT as there is no distinction.

We have made such a Platform RoT service, so you should be able to create a custom ARoT-service that can read out UICR using the same methodology as NS world would use. You will have to read the memory using the tfm_platform_mem_read functions:

https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/5454e8edfcb240e564405cc92708716e5846770c/platform/ext/target/nordic_nrf/common/core/services/include/tfm_ioctl_core_api.h#L88

But before you do that, you will have to add all the addresses that you want to be able to read in the memory range header file:

https://github.com/nrfconnect/sdk-nrf/blob/main/modules/trusted-firmware-m/tfm_boards/services/include/tfm_read_ranges.h

Note that the tfm_platform_mem_read service doesn't differentiate between NS or S service calls. If you add it in the tfm_read_ranges.h, then the NS-world would be able to request the same information

-Amanda H.

RE: TF-M Isolation Level is 1 with Profile Large

Maweb — Tue, 26 Mar 2024 14:53:54 GMT

Dear Amanda Hsieh

I could find out what causes the issue.

Within our custom secure service we access the UICR register to read the status of APPROTECT, ERASEPROTECT and SECUREAPPROTECT. This leads to the MemManage fault isses (if I comment it out, it works as expected).

Previously with Isolation Level 1 it worked with the code below within the secure service. How can we read the UICR from non-secure part without violating the memory access rules?

Best,

Manuel

    EN_protection protection = PROTECTION_NONE;
    uint32_t *APPROTECT = (uint32_t *)(0x00FF8000);
    uint32_t *ERASEPROTECT = (uint32_t *)(0x00FF8030);
    uint32_t *SECUREAPPROTECT = (uint32_t *)(0x00FF802C);
    if (*APPROTECT != 0xFFFFFFFF) {
        protection |= PROTECTION_ACCESS_PORT;
    }
    if (*ERASEPROTECT != 0xFFFFFFFF) {
        protection |= PROTECTION_ERASE_PROTECTION;
    }
    if (*SECUREAPPROTECT != 0xFFFFFFFF) {
        protection |= PROTECTION_SECURE_ACCESS_PORT;
    }

RE: TF-M Isolation Level is 1 with Profile Large

Amanda Hsieh — Tue, 26 Mar 2024 14:45:08 GMT

Hi,

What is the application? Are you using the sample or developing your application?

Could you provide the prj.conf and .conf under build/zephyr?

-Amanda H.

RE: TF-M Isolation Level is 1 with Profile Large

Maweb — Tue, 26 Mar 2024 08:30:10 GMT

Thanks Amanda Hsieh for looking at it. I really appreciate.

In the meanwhile I also tried to remove `CONFIG_TFM_PROFILE_TYPE_LARGE=y` and I added `CONFIG_TFM_IPC=y` and `CONFIG_TFM_ISOLATION_LEVEL=2`.

Isolation Level is now logged at `2`. However, I run now into a MemManage fault.

RE: TF-M Isolation Level is 1 with Profile Large

Amanda Hsieh — Mon, 25 Mar 2024 18:27:30 GMT

(updated)

[quote user=""]Is CONFIG_TFM_ISOLATION_LEVEL = 2 in general supported by Nordic SDK v2.6.0 on a nRF9160?[/quote]

Yes, see https://github.com/nrfconnect/sdk-nrf/blob/v2.6.0/samples/tfm/tfm_psa_template/prj.conf#L66

Our TF-M implementation officially supports either CONFIG_TFM_PROFILE_TYPE_NOT_SET or CONFIG_TFM_PROFILE_TYPE_MINIMAL . See Running applications with Trusted Firmware-M.

Removing CONFIG_TFM_PROFILE_TYPE_LARGE=y is supposed to make it work. (Remind: CONFIG_TFM_IPC should get y.) You can test with https://github.com/nrfconnect/sdk-nrf/tree/v2.6.0/samples/tfm/tfm_psa_template

Hi,

I can reproduce the issue. Let me check with the team and then get back to you.

Due to the Easter holidays in Norway, we are less staffed than usual. During this time, you may receive late responses. After next Monday, staff will return to normal. Sorry for the inconvenience and thanks for your patience.

Regards,
Amanda H.