- TF-M - lists.trustedfirmware.org

Getting started, ST B-U585I-IOT02A profile - compilation

by Tomasz Jastrzębski

Hi All, When I compile with GCC and Debug config (only Debug), process stops with these errors: [ 97%] Building C object bl2/CMakeFiles/bl2.dir/__/platform/ext/target/stm/common/hal/accelerator/stm .o [ 98%] Linking C executable ../bin/bl2.axf C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: address 0xc030fc4 of ../bin/bl2.axf section `.text' is not within region `FLASH' C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: ../bin/bl2.axf section `.ARM.exidx' will not fit in region `FLASH' C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: address 0xc030fc4 of ../bin/bl2.axf section `.text' is not within region `FLASH' C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: section .BL2_NoHdp_Code LMA [0c02a000,0c02a5a7] overlaps section .text LMA [0c014000,0c030fc3] C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: region `FLASH' overflowed by 28620 bytes Memory region Used Size Region Size %age Used FLASH_NVMCNT: 32 B 8 KB 0.39% FLASH: 118732 B 88 KB 131.76% FLASH_NOHDP: 1448 B 8 KB 17.68% FLASH_OTP: 756 B 4 KB 18.46% FLASH_NVM: 32 B 8 KB 0.39% RAM: 31624 B 63 KB 49.02% collect2.exe: error: ld returned 1 exit status make[5]: *** [bl2/CMakeFiles/bl2.dir/build.make:490: bin/bl2.axf] Error 1 make[4]: *** [CMakeFiles/Makefile2:1982: bl2/CMakeFiles/bl2.dir/all] Error 2 make[3]: *** [Makefile:136: all] Error 2 make[2]: *** [CMakeFiles/TF-M.dir/build.make:86: temp/src/TF-M-stamp/TF-M-build] Error 2 make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/TF-M.dir/all] Error 2 make: *** [Makefile:124: all] Error 2 Changing config to anything than Debug solves the issue, but along the way there are some warnings, of which these three seems to be particularly important: tests_reg/build_spe/build-spe/lib/ext/mbedcrypto-src/include/mbedtls/ecp.h:3 65: warning: "MBEDTLS_ECP_MAX_BYTES" redefined tests_reg/build_spe/build-spe/lib/ext/mbedcrypto-src/include/mbedtls/ecp.h:3 66: warning: "MBEDTLS_ECP_MAX_PT_LEN" redefined trusted-firmware-m/bl2/ext/mcuboot/config/mcuboot-mbedtls-cfg.h:132:2: warning: #warning "Use legacy driver API for BL2" [-Wcpp] 132 | #warning "Use legacy driver API for BL2" When I try to compile with Clang compiler latest version 6.21, I immediately get this error: C:\Temp\tf-m\tf-m-tests\tests_reg>cmake --build build_spe -- install [ 12%] Creating directories for 'TF-M' [ 25%] No download step for 'TF-M' [ 37%] No update step for 'TF-M' [ 50%] No patch step for 'TF-M' [ 62%] Performing configure step for 'TF-M' loading initial cache file C:/Temp/tf-m/tf-m-tests/tests_reg/build_spe/temp/tmp/TF-M-cache-Debug.cmake -- Found Git: C:/Program Files/Git/cmd/git.exe (found version "2.43.0.windows.1") -- The C compiler identification is unknown -- The CXX compiler identification is unknown -- The ASM compiler identification is ARMClang -- Found assembler: C:/Program Files/ArmCompilerforEmbedded6.21/bin/armasm.exe CMake Error at toolchain_ARMCLANG.cmake:190 (message): Please select newer Arm compiler version starting from 6.13. Call Stack (most recent call first): CMakeLists.txt:50 (tfm_toolchain_reload_compiler) -- Configuring incomplete, errors occurred! make[2]: *** [CMakeFiles/TF-M.dir/build.make:92: temp/src/TF-M-stamp/TF-M-configure] Error 1 make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/TF-M.dir/all] Error 2 make: *** [Makefile:124: all] Error 2 Please advise, Tomasz Jastrzębski

2 years, 2 months

2
2
0 0

Re: MemManage Fault during TF-M Secure Firmware Initialization

by Sari, Robert

Hi Jamie, thank you for the quick response! The culprit was indeed an MPU configuration that didn't comply with TF-M Isolation Level 2 requirements. Regards, Robert

2 years, 2 months

1
0
0 0

MemManage Fault during TF-M Secure Firmware Initialization

by robert.sari.ext＠siemens.com

Hello, I am currently having an issue during TF-M initialization where a MemManage fault is being triggered during secure FW initialization (most likely when the SPM is initialized). It appears to be an error during unstacking/returning from an exception as the MUNSTKERR bit of the MMFSR register is set. I receive the following exception context and exception frame when the error occurs: __________________________________________________________ FATAL ERROR: MemManage fault Here is some context for the exception: EXC_RETURN (LR): 0xFFFFFFFD Exception came from secure FW in thread mode. xPSR: 0x20000004 MSP: 0x20000BF8 PSP: 0x20002518 MSP_NS: 0x20042DF8 PSP_NS: 0xFFFFFFFC Exception frame at: 0x20002518 (Note that the exception frame may be corrupted for this type of error.) R0: 0x00000000 R1: 0x00000000 R2: 0x00000000 R3: 0x00000000 R12: 0x00000000 LR: 0xFFFFFFFE PC: 0x000358D1 xPSR: 0x01000000 CFSR: 0x00000008 BFSR: 0x00000000 BFAR: Not Valid MMFSR: 0x00000008 MMFAR: Not Valid UFSR: 0x00000000 HFSR: 0x00000000 SFSR: 0x00000000 SFAR: Not Valid __________________________________________________________ Other Information: - I am running Nordic Semiconductor's "tfm_psa_template" sample: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/nrf/samples/tfm/… - The Secure MPU is enabled (only the background region) before TF-M initialization begins - Board: nRF5340dk - TF-M Version: v1.8.0 - TF-M Isolation Level: 2 My questions are: - What part of the TF-M FW could be the cause of this MemManage fault? - Is there any way to solve this issue (such as a different TF-M configuration) so that TF-M will initialize properly? Regards, Robert Sari

2 years, 2 months

2
1
1 0

Memory Footprint Table generation

by Ruchika Gupta

Hi, With every TFM release, I see that there is a memory footprint table<https://trustedfirmware-m.readthedocs.io/en/latest/releases/2.0.0.html#refe…> which is made available for the AN521 platform. Are there any scripts available to run on the map file/other binaries to generate this table ? I would like to use the same for our platform and do some analysis. Further question- Why is there a tie up between the large profile with TFM isolation level 3 ? Is it a certification requirement ? Regards, Ruchika

2 years, 2 months

3
2
0 0

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

by Lee, William

Hi Antonio, Thank you for your information, it is very helpful. Best regards Tao Li (William Lee) Software Engineer @ Garmin Mobile: +8618628138760 From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Reply-To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> Date: Monday, January 1, 2024 at 06:58 To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe. 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…<https://urldefense.com/v3/__https:/developer.nordicsemi.com/nRF_Connect_SDK…> 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…<https://urldefense.com/v3/__https:/www.psacertified.org/app/uploads/2021/12…> Sent from Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/AAb9ysg__;!!EJc4YC3iFmQ!X1Zeo-qnf…> ________________________________ 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…<https://urldefense.com/v3/__https:/www.nxp.com/products/processors-and-micr…> Thank you! Best regards William Lee

2 years, 2 months

1
0
0 0

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

2 years, 2 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

2 years, 2 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

2 years, 2 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>

2 years, 2 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>

2 years, 3 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

2 years, 3 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>

2 years, 3 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

2 years, 3 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.

2 years, 3 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>

2 years, 3 months

3
5
0 0

[RFC] Bump minimum CMake version required

by David Hu

Hi all, The current minimum CMake version specified in TF-M is 3.15. It is quite out-of-date. I’d like to propose to increase minimum CMake version to 3.21. CMake 3.21 can bring in some benefits, compared to CMake 3.15 * NEW behavior of several CMake policies, such as CMP0123 for Armclang. * After build split, TF-M secure build installs several build scripts. When NS build includes those build scripts, `CMAKE_CURRENT_FUNCTION_LIST_FILE/DIR` can make it easier to handle source code paths. CMake 3.21 was released 2 years ago. It should be stable enough now. May I know if you have any feedback or different opinions? Thank you. Best regards, Hu Ziji

2 years, 3 months

2
4
0 0

Reduce dependency of NS Mailbox structure on non-secure configurations

by Roman.Mazurak＠infineon.com

Hi all, I faced the problem that mailbox configuration of secure image differs from one provided for non-secure. It's because I'm using a split-build but a little bit different that is prepared for v2.0. I think we can minimize dependencies and unexpected impacts between different images when common data structures will have less customization. Currently we have three options that can change mailbox structures: 1. NUM_MAILBOX_QUEUE_SLOT - number of mailbox slots 2. TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD - defines which NS client implementation is selected. 3. TFM_MULTI_CORE_TEST - specify whether NS multi-core test suite is built. There is requirement that NUM_MAILBOX_QUEUE_SLOT must be set to 1 if NS bare metal environment is used. But this limitation is excessive. Because it's important that secure side is not using slots that are not used by non-secure side. It can be possible to use NS bare metal client even if mailbox queue size is more than one, it's just the waste of resources in such case. But it can bring a benefit that it's possible to build secure image with default settings (aka 4 mailbox slots) and there is no need to rebuild it if there will be decision to switch from RTOS to bare metal environment which can be useful for some end-user use cases. More flexible update will be to pass number of allocated slots from NS side to TF-M during initialization, it's just important to validate that number of slots doesn't not exceed maximum supported by design. TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD is another problem, because mailbox_reply_t allocates data that are not shared but used by non-secure side only. Which means that it's important to decide which NS client implementation is going to be used when TF-M is built. I see two different solutions for this problem: 1. Use union to allocate space for both of them and let decide NS client implementation which on to use. Something like this: struct mailbox_reply_t { union { //#ifdef TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD uint8_t *woken_flag; /* Indicate that owner task has been * or should be woken up, after the * reply is received. */ //#else bool is_woken; /* Indicate that owner task has been * or should be woken up, after the * reply is received. */ //#endif }; }; 1. Redesign mailbox by separating data that are used by NS client from data that are shared between cores. So, it will be much easier to update non-secure client without touching secure image. It looks like there is data needed for test suite only (nr_tx and nr_used_slots fields of ns_mailbox_queue_t) defined by TFM_MULTI_CORE_TEST. I think we can allocate it in test suite only, so there will be no need to allocate this data in shared structure and there will not be the case when location of is_full field of ns_mailbox_queue_t accessed by both cores have different location if TFM_MULTI_CORE_TEST configuration is not applied the same way for both secure and non-secure images. Regards, Roman.

2 years, 3 months

3
7
0 0

FPU flags for mbedTLS targets

by Quach, Brian

Hi, /secure_fw/partitions/crypto/CMakeLists.txt is missing passing compiler flags to mbedTLS targets which would be needed for correct FPU flags. I believe the highlighted code would be the fix: target_compile_options(${MBEDTLS_TARGET_PREFIX}mbedcrypto PRIVATE ${COMPILER_CP_FLAG} $<$<C_COMPILER_ID:GNU>:-Wno-unused-const-variable> $<$<C_COMPILER_ID:GNU>:-Wno-unused-parameter> $<$<C_COMPILER_ID:ARMClang>:-Wno-unused-const-variable> $<$<C_COMPILER_ID:ARMClang>:-Wno-unused-parameter> ) target_compile_options(${MBEDTLS_TARGET_PREFIX}p256m PRIVATE ${COMPILER_CP_FLAG} ) Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

2 years, 3 months

2
5
0 0

compile error when PS_ENCRYPTION=OFF

by Quach, Brian

Hi, if I set PS_ENCRYPTION=OFF set(PS_ENCRYPTION OFF CACHE BOOL "Enable encryption for Protected Storage partition") I see this compile error: In file included from /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/tfm_internal_trusted_storage.c:32: /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:48:31: error: 'PS_TAG_LEN_BYTES' undeclared here (not in a function) 48 | #define PS_TAG_IV_LEN_MAX ((PS_TAG_LEN_BYTES > PS_IV_LEN_BYTES) ? \ | ^~~~~~~~~~~~~~~~ /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:60:20: note: in expansion of macro 'PS_TAG_IV_LEN_MAX' 60 | uint8_t tag_iv[PS_TAG_IV_LEN_MAX]; | ^~~~~~~~~~~~~~~~~ /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:48:50: error: 'PS_IV_LEN_BYTES' undeclared here (not in a function) 48 | #define PS_TAG_IV_LEN_MAX ((PS_TAG_LEN_BYTES > PS_IV_LEN_BYTES) ? \ | ^~~~~~~~~~~~~~~ /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:60:20: note: in expansion of macro 'PS_TAG_IV_LEN_MAX' 60 | uint8_t tag_iv[PS_TAG_IV_LEN_MAX]; | ^~~~~~~~~~~~~~~~~ make[7]: *** [secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/build.make:90: secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/tfm_internal_trusted_storage.o] Error 1 I think the correct fix is to add the following highlighted code to ps_object_defs.h. Patch is attached. /*! * \struct ps_object_t * * \brief The object to be written to the file system below. Made up of the * object header and the object data. */ struct ps_object_t { struct ps_obj_header_t header; /*!< Object header */ uint8_t data[PS_MAX_OBJECT_DATA_SIZE]; /*!< Object data */ #ifdef PS_ENCRYPTION uint8_t tag_iv[PS_TAG_IV_LEN_MAX]; #endif }; Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years, 3 months

2
1
0 0

psa_call with NULL outvec causes a NULL pointer dereference

by Quach, Brian

Hi, Is it possible to call psa_call() with NULL outvecs with TF-M v2.0? I am using IPC model. This worked for me with TF-M v1.8 but now I see get a NULL pointer dereference with TF-M v2.0 when psa_reply() is called. Specifically, it happens inside update_caller_outvec_len(). It seems msg.out_size[i] is non-zero (due to a previous psa_call which had 3 outvecs). handle->caller_outvec[i].len causes a NULL pointer deference. void update_caller_outvec_len(struct connection_t *handle) { uint32_t i; for (i = 0; i < PSA_MAX_IOVEC; i++) { if (handle->msg.out_size[i] == 0) { continue; } SPM_ASSERT(handle->caller_outvec[i].base == handle->outvec_base[i]); handle->caller_outvec[i].len = handle->outvec_written[i]; } } spm_associate_call_params() does not clear msg.out_size[] so the previous contents remain. One potential fix is to add the highlighted code below to clear out_size[]. [cid:image001.png@01DA27A5.8860E6F0] Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

2 years, 3 months

2
3
0 0

Partition log write UART without validation of permissions.

by Roman.Mazurak＠infineon.com

Hi all, I noticed that partition log subsystem uses stdio_output_string through following chain of calls tfm_hal_output_sp_log => SVC TFM_SVC_OUTPUT_UNPRIV_STRING => tfm_hal_output_spm_log => stdio_output_string. SVC handler doesn't validate arguments, so it's allows APP RoT partitions to access PSA RoT memory via partition log subsystem. It seems that tfm_hal_memory_check must be called on SVC handler to validate permissions. Best Regards, Roman.

2 years, 3 months

2
1
0 0

preload.cmake

by Quach, Brian

Hi, I'm seeing references in the documentation for preload.cmake and several files with that name in TF-M v2.0.0. But looking at the code it seems like preload.cmake was replaced with cpuarch.cmake. Am I missing something? Where should be put fixed platform-specific definitions which are not related to CPU architecture? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years, 3 months

2
3
0 0

Redundant check on FWU_DEVICE_CONFIG_FILE

by Bohdan.Hunko＠infineon.com

Hi all It seems to me like following check # FWU_DEVICE_CONFIG_FILE exists and is a file if(NOT EXISTS ${FWU_DEVICE_CONFIG_FILE}) message(FATAL_ERROR "FWU_DEVICE_CONFIG_FILE:${FWU_DEVICE_CONFIG_FILE} does not exist.") elseif(IS_DIRECTORY ${FWU_DEVICE_CONFIG_FILE}) message(FATAL_ERROR "FWU_DEVICE_CONFIG_FILE:${FWU_DEVICE_CONFIG_FILE} is a folder while a file is expected.") endif() in secure_fw/partitions/firmware_update/CMakeLists.txt is redundant as FWU_DEVICE_CONFIG_FILE may be generated, thus not present when cmake performs EXISTS check (note that by default FWU_DEVICE_CONFIG_FILE is generated so I dont see point in limiting user from using generated file) So i propose to remove this check. 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>

2 years, 3 months

2
6
0 0

TF-M release v2.0.0 announcement

by Anton Komlev

Hello, I am happy to announce the new release of TF-M v2.0.0<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv2.0…>. The major version update indicates the important changes in the way TF-M builds. New major features are: * TF-M secure build process and non-secure build process are split. * Refer to TF-M Build Instruction to build SPE image. * Refer to Building Tests to build non-secure tests. * Update new Mailbox agent API. * Decouple the specific application Mailbox from SPM, make it an application in Secure Partition. * Unify the interfaces between partitions and SPM, and reduces the interaction interface between them. * Multi-core support in the Secure Function (SFN) model. * Optimize SPM critical section implementation to reduce time cost in isolation level 2&3. * Use local variables for connection handles instead of dynamic allocation. * P256-M component is enabled on the TF-M side in profile medium. * MCUboot upgrade to v2.0.0. * Mbed TLS upgrade to v3.5.0. * TF-M PSA client API performance profiling is tracked in SQUAD and the profiling tool is updated. * TF-M integrates Read the Docs. Please check the release notes<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/25143/12/doc…> for more information. The release branch changes will be ported to the main branch shortly. Many thanks to everyone for contributing, reviewing and supporting this milestone. Anton

2 years, 3 months

2
1
0 0

Deprecate Laird Connectivity platform

by Andersson, Joakim

The Laird Connectivity platform board BL5340 DVK no longer compiles in the main branch of TF-M after the split build feature was merged. The BL5340 DVK is a module that contains the nRF5340 SoC, because of this the platform is re-using the Nordic platform support files. This cross-reference is causing us, the maintainers of Nordic a lot of problems as making changes to the Nordic platform code can break the Laird Connectivity platform. We don't have this board either to run any tests and confirm any changes. Laird Connectivity has not contributed to the platform support for more than a year. Nordics strategy for maintaining support for TF-M is to have the base DK supported in TF-M for testing purposes, and then provide support for all other boards in our SDK through our board support configuration system. Removing the platform from TF-M will still mean that the BL5340 DVK board is supported in the nRF Connect SDK. To support the board in the Zephyr Project the following PR is needed: https://github.com/zephyrproject-rtos/zephyr/pull/65823 Joakim Andersson Nordic Semiconductor

2 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M