- TF-M - lists.trustedfirmware.org

Re: Are MCUs without internal flash not supported by TF-M?

by Antonio De Angelis

Hi Torsten, you can have a look at the design document for ITS which describes encryption in ITS for a generic introduction: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/tfm/design_docs… A platform supports ITS_ENCRYPTION=ON if it provides an implementation of the HAL functions as follows: tfm_hal_its_aead_* For the exact list of Nordic platforms that support this option I suggest to have a look directly in the Nordic Connect SDK. Probably any platform based on the 5340 would be able to support this option, but there might be other platforms as well which you would be able to use through the SDK itself. Hope this helps. Thanks, Antonio ________________________________ From: Labs, Torsten via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Saturday, December 30, 2023 14:51 To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; Lee, William <William.Lee(a)garmin.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? Hi antonio, Thanks for those interesting news. Do you know on which Nordic platform supports encrypted ITS with TFM? Regards Torsten ________________________________ Von: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Gesendet: Saturday, December 30, 2023 9:31:10 AM An: Lee, William <William.Lee(a)garmin.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Betreff: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? Hi William, The requirement on the storage is for it to be isolated, either physically or cryptographically, as you can read from the PSA security model [1]. TF-M initially supported only the isolated model in ITS (i.e. for internal flashes) but more recently it was added support for encrypted ITS, which I believe it can be used on one of the Nordic platforms already. Hope this helps. Thanks, Antonio [1] Platform Security Model - PSA Certified https://www.psacertified.org/app/uploads/2021/12/JSADEN014_PSA_Certified_SM… Sent from Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Lee, William via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Friday, December 29, 2023 5:53:50 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Are MCUs without internal flash not supported by TF-M? Hello everyone, Happy New Year! Are MCUs without internal flash not supported by TF-M? From TF-M’s documents, I saw ITS(Internal Trusted Storage) is a PSA-ROT secure service and requires store data in internal flash. Does that mean TF-M not support hardware platforms that do not have internal flash? For example, RT500 does not have internal flash: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… Thank you! Best regards William Lee

1 year, 6 months

1
0
0 0

Are MCUs without internal flash not supported by TF-M?

by Lee, William

Hello everyone, Happy New Year! Are MCUs without internal flash not supported by TF-M? From TF-M’s documents, I saw ITS(Internal Trusted Storage) is a PSA-ROT secure service and requires store data in internal flash. Does that mean TF-M not support hardware platforms that do not have internal flash? For example, RT500 does not have internal flash: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… Thank you! Best regards William Lee

1 year, 6 months

3
2
0 0

Minor updates to the tf.org project maintenance

by Sandrine Bailleux

Hello TF-A and TF-M communities, I've done 2 minor updates to the generic tf.org project maintenance process, which TF-A and TF-M both use. Please see the pull request here: https://github.com/TrustedFirmware/tf_docs/pull/1 Please provide your feedback on the pull request, if any. Happy end-of-year celebrations to all! Best regards, Sandrine

1 year, 6 months

1
0
0 0

Arm v8 FPU questions

by Bohdan.Hunko＠infineon.com

Hi all, I have been working with FPU lately and I have a few questions regarding this topic: Looks like there are 4 use cases of FPU usage: FPU is used in Use case number SPE NSPE 1 - - 2 - + 3 + - 4 + + From https://tf-m-user-guide.trustedfirmware.org/integration_guide/tfm_fpu_suppo… my understanding is following: 1. If SPE and NSPE both does not use SPU (use case 1) then they both must be compiler with fp=soft? 2. consistent FP ABI types between SPE and NSPE must be used. So even if only one of SPE or NSPE (use cases 2 and 3) does not use FPU they both still must be compiler with fp=hard Also if both SPE and NSPE use PFU then they both must be compiler with fp=hard 3. Even if FPU is not used by NSPE, NSPE still MUST enable CP10 an CP11? - Is this correct? Is it possible to enable FPU for SPE but don't enable CP10 and CP11 in NSPE? So basically if either SPE or NSPE or both of them need to use FPU then both of them need to enable CP10 and CP11 and be compiled with fp=hard Is my understanding correct? Inline comments are welcome. Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

1 year, 6 months

2
1
0 0

How to disable all interrupts on ARM V8?

by Bohdan.Hunko＠infineon.com

Hi all, From what I have seen, looks like __disable_irq() only disables non-secure interrupts when called from NSPE on ARM v8 arch. Am I correct? If so then how can I disable all interrupts (including secure interrupts) from NSPE? - We need this for critical section and other critical code. Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

1 year, 6 months

2
1
0 0

Problems with integrating TF-M with RIOT OS

by Boeckmann, Lena

Hi everyone! I am currently integrating TF-M with an IoT OS (RIOT OS) and I have a few problems. I managed to build and link a secure TF-M binary and a non-secure RIOT binary and I can run some application code (print "hello world", turn LEDs on and off, etc) on the nRF9160dk. I can also use the crypto API and call psa_crypto_init. Now I have tried a few things and each of them leads to different problems, some of which I will describe in this mail hoping that someone can help me with this. I have done some debugging and have some ideas on what could be wrong, but I don't really understand how to fix the issues and don't really know how to proceed with either of them. Formatted Prints Somehow formatted prints are ignored. Calls to printf without formatting default to the stdio puts implementation and are printed without issues. Calls to printf with formatting use the implementation in tfm_sp_log_raw.c and are just ignored. They crashed at first, but I could fix that (RIOT has different implementations of the SVC ISR and I used the wrong one). Now they don't crash anymore, but are also not printed (no error output, application keeps running). Since this function is part of the secure firmware, my guess is that there's a problem with it being called from the NS world. But that should result in a SecureFault, shouldn't it? Does anyone have an idea what the issue could be? Secure memset called from NS image When calling psa_generate_key, the first step is a struct initialization: struct tfm_crypto_pack_iovec iov = { .function_id = TFM_CRYPTO_GENERATE_KEY_SID, }; This runs into a SecureFault. It turns out that during struct initialization, memset is called to zeroize the structure. This uses the memset implemented in secure_fw/shared/crt_memset.c and accesses secure RAM (between addresses 0x20015000 and 0x20016000). I found a workaround by moving the start address of NS RAM from 0x20016000 to 0x20020000. Memset now still accesses RAM before NS RAM, but does not run into a SecureFault anymore. This works for now, but I would like to find an actual fix for this. This only occurs when building with RIOT. When building the TF-M NS image and running crypto tests, memset accesses NS RAM, though I don't know if the same implementation is used. Unfortunately I don't get any debug symbols there. Could it be that a different memset implementation should be linked? Can I change it somehow? Can someone tell me which one is linked in the TF-M NS image? Crypto partition is NULL When using the workaround described above, calling psa_generate_key runs into tfm_core_panic. The stack trace here is: psa_call (tfm_psa_call.c) tfm_psa_call_pack (backend_sfn.c) tfm_spm_client_psa_call (psa_call_api.c) tfm_spm_is_ns_caller (spm_ipc.c) The problem is in tfm_spm_is_ns_caller, where struct partition_t *partition = GET_CURRENT_COMPONENT(); gets a NULL pointer. So somehow there is no crypto partition available. Of course I have enabled the crypto partition in config_base.cmake, as well as protected storage and internal trusted storage. I checked with a debugger and found out that during start up, multiple partitions are initialized and added to the global component list (stored in backend_sfn.c). Can I somehow check what types of partitions are initialized? Did anyone have a similar issue before or has any idea why the partition could be missing? Did I miss any extra steps I need to take? I know these are pretty much unrelated issues, but they are persistent and I am at a loss at how to fix them. I will take any hints and ideas, including pointers to where I can find relevant information in the docs (those have not been very helpful in these cases, but maybe I've overlooked something). Best regards, Lena

1 year, 6 months

2
2
0 0

Weird behavior of Clang linker

by Bohdan.Hunko＠infineon.com

Hi all, Our platform uses 4KBs alignment in linker files (as this is the requirement of our protection HW). For this reasons I have introduced tfm_s_linker_alignments.h. Everything works fine with GCC but we have a problem with Clang. The problem is that Clang requires LR_CODE to have same alignment as other sections inside of it. Following are the steps to reproduce the issue: 1. Set TFM_LINKER_DEFAULT_ALIGNMENT to 0x1000 in tfm_s_linker_alignments.h 2. Build AN521 with following command line cmake -S . -B build_an521 -DTFM_PLATFORM=arm/mps2/an521 -DTFM_TOOLCHAIN_FILE=./toolchain_ARMCLANG.cmake Expected result: Everything works fine Actual result: Error: L6244E: Load region LR_CODE address (0x10080400) not aligned on a 4096 byte boundary. This error is weird because there is no explicit alignment assigned to LR_CODE region. Would appreciate a help on this as it is a blocking issue for us. Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

1 year, 6 months

3
3
0 0

Re: Attestation token new spec

by Tamas Ban

Hi, Sorry 2nd link was broken. Here is the working version: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab… Tamas Ban From: Andersson, Joakim <Joakim.Andersson(a)nordicsemi.no> Sent: 2022. május 9., hétfő 12:14 To: Tamas Ban <Tamas.Ban(a)arm.com> Subject: RE: Attestation token new spec Is te second link broken? I get a 404 error code. -Joakim From: Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: mandag 9. mai 2022 11:31 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Attestation token new spec Hi, the initial attestation token implementation is aligned with this specification: https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-05<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack…> This spec is still evolving and there is a newer version which changes the key values of the claims in the token: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab…<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.…> This can cause combability issues between token issuer (device) and token verifier (some remote verification service). This is an ABI change between token issuer and consumer. The breaking effect would be manifest in unaccepted IAT tokens by the verifier. On-device side I see these options to make the transition: - A build-time option could be introduced which determines which range of key numbers to use. The default value would be the new range. To not let new users pick up the old values accidentally. Existing users can notice the incompatibility issue during the integration test and adjust their build command accordingly. However, the old range would be announced as deprecated in the next TF-M release, then will be removed in the next release after. - Immediate switch over to the new range, without supporting the old range anymore. On the verification service side, an SW update can handle the transition and might be accepting both ranges for a while. I assume the verification service can be updated more easily than remote devices therefore better to handle the compatibility issue there. - Keeping the support for both ranges for the long term and letting users choose by build time. Please share your thoughts on: - Are you aware that the attestation service is used in deployed devices where this transition can cause incompatibility? - From the above list which option would you vote to support the transition? Best regards, Tamas Ban

1 year, 6 months

3
4
0 0

FIH volatile structure and stack usage

by Roman.Mazurak＠infineon.com

Hi all, I found that using FIH medium/high profile with gcc generates code that uses stack extensively. It happens because fih_int structure is marked as volatile. Is there any reason why structure itself is marked as volatile? Why it's not enough to make val and msk volatile members of fih_int structure? Best regards, Roman.

1 year, 6 months

2
4
0 0

Redundant checks in FWU code

by Bohdan.Hunko＠infineon.com

Hi all, In config/check_config.cmake there is a following code: tfm_invalid_config((MCUBOOT_UPGRADE_STRATEGY STREQUAL " DIRECT_XIP " OR MCUBOOT_UPGRADE_STRATEGY STREQUAL "RAM_LOAD") AND TFM_PARTITION_FIRMWARE_UPDATE) So looks like FWU is not supported when DIRECT_XIP or RAM_LOAD upgrade strategies are used. But then in FWU code I see a lot of checks for DIRECT_XIP or RAM_LOAD, for example in fwu_bootloader_get_image_info: #if !defined(MCUBOOT_DIRECT_XIP) && !defined(MCUBOOT_RAM_LOAD) && \ !defined(MCUBOOT_OVERWRITE_ONLY) What is the point of these checks if it is impossible to compile FWU code with DIRECT_XIP Because of check in config/check_config.cmake? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

1 year, 6 months

3
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M