- TF-M - lists.trustedfirmware.org

Can primary and secondary images have clearly different sizes?

by tomasz jastrzebski.net

Hi All, I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size, hence the latest version may be clearly larger than the previous one. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. LL1 size may be clearly different than LL2, Local Loader update may result in the Main App update, but that is OK. Does TF-M support the described scenario? Flexibility is the key. Can primary and secondary Local Loader (LL) images have clearly different sizes? Kind regards, Tomasz Jastrzębski https://drive.google.com/file/d/1n4Ihqk8S-04FlluvlveQflb5nYsXBluA/view?usp=… [cid:image001.png@01DA4F08.95319C00]<https://drive.google.com/file/d/1n4Ihqk8S-04FlluvlveQflb5nYsXBluA/view?usp=…>

2 years, 1 month

2
3
0 0

Pre-encryption image compression (re-posting as a new topic)

by Tomasz Jastrzębski

Hello All, Does the current TF-M version support image compression before image is encrypted? Needless to say, compression after the image has been encrypted would not yield reasonable compression ratio. I am showing that *.bin files, even built with MinSizeRel option, zip-compress with minimum 50% compression ratio so probably this would make sense. Tested with STM32U5 target and GCC. "PSA Certified Firmware Update API <https://arm-software.github.io/psa-api/fwu/1.0/overview/architecture.html#m anifest> " document in sections 3.1 and 3.2 provides for image compression. Kind regards, Tomasz Jastrzębski

2 years, 1 month

2
2
0 0

SFN vs IPC partition with IPC backend

by Quach, Brian

If using IPC backend, how much performance and/or memory savings is there when using SFN vs IPC partition model? I saw FF-M v1.1 recommended SFN partition model but it was not clear to me why it was preferred. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

2 years, 2 months

3
6
0 0

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

How can use Mailbox in TF-M on Dual-core System ?

by 진국 박

hello. I have ported corestone1000 plaform to tfm and am trying to use mhu to send and receive messages between secure enclave (SPE)core and host core(NSPE). (I want to use it for future encryption requests). Looking at the rss platform and corstone-1000 tfm code, the function for initializing and registering the mhu seems to be tfm_inter_core_comm_init. But I can't find the part that calls tfm_inter_core_comm_init. Can anyone tell me the procedure and a simple example of sending and receiving messages using MHU in a TFM environment? I've been looking through the TFM documentation, but I can't find it yet. Below is the tfm_inter_core_comm_init function to register the rpc of the spe in rss. I was wondering where the function below is called and used. int32_t tfm_inter_core_comm_init(void) { int int32_t ret; /* Register RPC callbacks */ ret = tfm_rpc_register_ops(&rpc_ops); if (ret != TFM_RPC_SUCCESS) { return ret; } /* Platform specific initialization */ ret = tfm_multi_core_hal_init(); if (ret != TFM_PLAT_ERR_SUCCESS) { tfm_rpc_unregister_ops(); return ret; } } return TFM_RPC_SUCCESS; } You are a newbie to TFM and are looking for help.

2 years, 3 months

3
3
0 0

Flashing problems on B-U585I-IOT02A

by João Bento

Hello, I have recently trying to flash the B-U585I-IOT02A board by running the 3 scripts generated in the build folder, as I usually do with the STM32L552 board. However, I encountered some unexpected errors as I noticed that the secure and non-secure images were being written to external flash address spaces. I quickly noticed that this was happening because the "flash_layout.h" file defines the variable "EXTERNAL_FLASH". Additionally, the "image_macros_to_preprocess_bl2.c" set the image as encrypted by default with "RE_IMAGE_ENCRYPTED= 0X01", causing the "TFM_UPDATE.sh" script to write to the secondary slots. I found it quite strange because tf-m presented an off-the-shelf solution for the other board while for this board it assumes the use of an external flash. Nevertheless, I tried to work around these limitations by commenting the EXTERNAL_FLASH variable and assigning the "RE_IMAGE_ENCRYPTED= 0X00" similarly to the stm32l552. This led to the images being written to the primary slots defined in the flash layout, however, in runtime I encountered an error that states "Unable to find bootable image". Therefore, my question is: Do I need to make further adjustments, or is it possible that there's a configuration issue that is not compatible with the board? Best regards, João Bento

2 years, 4 months

2
4
0 0

Start of TF-M v2.0.0 release

by Anton Komlev

Hello, The branch release/2.0.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=release/…> has been created indicating the start of the release process and features freeze. RC1 tag will follow after a successful run of the basic tests. Let me remind that the code is not frozen, and development can be continued on the main branch as described in TF-M Release Process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Thanks, Anton

2 years, 4 months

1
2
0 0

PSA_FRAMEWORK_HAS_MM_IOVEC

by Quach, Brian

Hi, I saw that PSA_FRAMEWORK_HAS_MM_IOVEC is not permitted for Isolation level 2-3 and transient copies of the input and output data into a 5KB scratch buffer are always made when making a PSA call. This makes sense as FF-Mv1.1 states: “In a system using isolation level 3, a Secure Partitions is not permitted to access another Secure Partition’s Private data. MM-IOVEC can provide a mechanism for one Secure Partition to access the other’s Private data.” But I think the requirements for isolation level 3 could be fulfilled by: If SP detects a Secure caller, it could make a transient copy of I/O data. If SP detects a Non-Secure caller, it could use MMIOVECs or a similar method to access NS memory directly to avoid overhead and limitations of copying the I/O data. Is this logical/ correct? With this approach, an attacker may tamper NS input data while the RoT service is processing those data but rules of isolation level 3 are maintained. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years, 4 months

2
3
0 0

Various issues in successfully using GDB to debug secure apps on Musca S1 connected over USB DAPLink to a Linux host

by Arun D

Now sure where exactly this belongs, but I already posted question abut the Musca S1 earlier, and this seems relevant. ARM support essentially seem to tell me that they cannot support GDB and they are not certain of DAPLink, and recommend ULINKPLUS debugger with ARM IDE. So wanted to get a sense from anyone who has attempted to use this. In the following I describe the steps to obtain a base line, then provide description in what way GDB / DAPLink seems to misbehave. To get a base line: ~~~~~~~~~~~~~ - I build 'samples/hello_world' app using Zephyr 'v3.4.0'. Copy the 'build/zephyr/zephyr.hex' file to '/media/user/MUSCA_S1' directory when the board is USB. Connect a terminal emulator to the UART exposed by USB DAPLink, e.g. 'picocom -b 115200 -y n /dev/ttyACM0'. I can see on the console the followinbg *** Booting Zephyr OS build zephyr-v3.4.0 *** Hello World! musca_s1 If I press the reset button, the app restarts as well. This is as expected. I note that this is entirely running as in secure mode, that it does not use TF-M. - Next I start 'pyocd-gdbserver'. Then start a GDB session using the 'zephyr.elf' file, 'target remote localhost:3333' to connect it to the gdbserver. It connects ok. So I put a breakpoint at "main", do a 'monitor reset halt', and then continue. The breakpoint at 'main' is hit, I can obtain the backtrace to see it is correct as expected. So my setup seems good. Next I attempt to test a non-secure app with TF-M. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Build the app using Zephyr build env 'west build -b v2m_musca_s1_ns samples/tfm_integration/tfm_psa_test/ -DCONFIG_TFM_PSA_TEST_CRYPTO=y'. Copy 'build/zephyr/tfm_merged.hex' to '/media/user/MUSCA_S1'. Connect a terminal emulator, picocom, to the console, and hit the PBON (power on) button. I see the following output as expected on the console: Musca-S1 Dual Firmware Version 1.9 [WRN] This device was provisioned with dummy keys. This device is NOT SECURE [Sec Thread] Secure image initializing! Booting TF-M 79a6115d3 [INF][Crypto] Initialising HW accelerator... complete. *** Booting Zephyr OS build zephyr-v3.4.0 *** ***** PSA Architecture Test Suite - Version 1.4 ***** Running.. Crypto Suite ****************************************** TEST: 201 | DESCRIPTION: Testing crypto key management APIs | UT: psa_crypto_init [Info] Executing tests from non-secure This is as expected. However, if I press the reset button the board does not appear to reset - this is unexpected. Has anyone seen a different behavior? Is the specific board that I have is misbehaving? - Now I start PyOCD GDB server, start GDB and successfully connect it to the GDB server. The target is halted where it was executing, e.g. Remote debugging using localhost:3333 CC_HalWaitInterruptRND (data=data@entry=1024) at /home/zephyr/zephyrproject/modules/tee/tf-m/trusted-firmware-m/lib/ext/cryptocell-312-runtime/host/src/hal/cc3x/cc_hal.c:107 107 irr = CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_IRR)); (gdb) This is as expected. - Next I put a breakpoint at 'sprt_main', then issue a 'monitor reset halt', then issue a 'continue', The breakpoint is is NOT hit. I see a blue LED blink at perhaps 4 times per second. This is unexpected. Has anyone seen this behave correctly? Do I have a board that is misbehaving?

2 years, 4 months

4
10
2 0

Building TF-M for ARM reference SoC/boards MPS2/MPS3 and Musca S1

by capablegh＠gmail.com

Hello. The ARM MPS2/MPS3 have Cortex M33 two processor configuration. I am building TF-M under the Zephyr OS setup. From the build it appears that the secure (TF-M) and non-secure (Zephyr OS and app) are bound and executed on separate CPUs. Assuming that two CPUs are used, in the build, is there a way to force using same one CPU for TF-M and Zephyr/app, while disabling the second CPU? Thanks.

2 years, 4 months

5
12
1 0

Increasing the flash partition for the Secure Firmware in TF-M for MPS2-AN521 board emulated using Qemu

by Gowri Ramshankar

Problem: ARoT app is too large, that the image build fails. Error: /home/gramshan/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: bin/tfm_s.axf section `.ER_UNPRIV_CODE' will not fit in region `FLASH' /home/gramshan/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: region `FLASH' overflowed by 114956 bytes Memory region Used Size Region Size %age Used FLASH: 572684 B 447 KB 125.11% RAM: 54556 B 1 MB 5.20% To overcome this issue, I changed the flash_layout header file (https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/platfo…) such that the secure side size is (FLASH_S_PARTITION_SIZE) 700+KB from the 512KB default for the MPS2 AN521 app, and correspondingly update the non-secure side FLASH_NS_PARTITION_SIZEto be 300KB. This builds the tfm_merged.hex file, But fails it to boot the app. So, I do not use your ARoT, but just built as non-secure app - the 'hello_world' Zephyr app that prints a one line hello_world on the console, but using the modified partition layout. This too fails to boot, in that the "hello world" is not printed. I debugged this to find that it is BL2 that is failing. I see that the Panic occurs during the image swapping operation, this is because the image to be filled in the primary slot is identified as invalid and the secure boot stops. The TF-M thinks some firmware upgrade is happening, the integrity check fails and panics, thus inducing a Fault Injection Hardening defense. Now I am stuck with this issue and I do not know how to proceed further, any help on how to change the flash partition sizes in a clean manner would be appreciated.

2 years, 4 months

3
5
0 0

Scheduling bug

by Bohdan.Hunko＠infineon.com

Hi There seem to be scheduling bug we have found in SPM. This bug is related to handling of interrupts that arrives during SVC call and assert signed for partition. Steps to reproduce: 1. Call psa_wait() from partition (e.g. mailbox partition) 2. During execution of SVC handler generate Interrupt that asserts signal of that partition (e.g. mailbox partition signal ) (adding long delay in SVC handler or adding breakpoint in SVC handler helps to easier reproduce this ) 3. Following sequence happens: * Mailbox IRQ has lower priority than SVC thus SVC is not preempted. * SVC sees that mailbox partition is blocked (as it is waiting for signal and no signals are pending) * SVC triggers pendSV i. Mailbox IRQ and pendSV are both pending * Mailbox IRQ has higher priority than pendSV thus Mailbox IRQ is executed * Mailbox IRQ calls spm_handle_interrupt i. Signal is asserted thus spm_handle_interrupt in thrd_next calls query_state_cb which returns THRD_STATE_RET_VAL_AVAIL and thus tfm_arch_set_context_ret_code is called ii. tfm_arch_set_context_ret_code sets return code using OLD value of partition PSP (as it was never updated, as it is updated in PendSV) * Mailbox IRQ return, pendsv is started and it runs mailbox partition i. Mailbox partition has 0 as signal because return value was written to wrong location is stack Patch I have attached to the mail solves this problem for us BUT it seems more like a workaround than a proper fix( Anyways it would be nice to have this problem review by SPM experts and have proper fix (maybe we have other places with same problem...) 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, 4 months

2
2
0 0

Merging build split feature branch back to main branch

by David Hu

Hi, I’d like to give you a heads-up that build split feature branch will be merged back to main branch very soon this week. Trusted-firmware-m build split branch: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/?h=feature… Tf-m-tests build split branch: https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/?h=feature-build-s… Build split feature improves how NS side integrate with TF-M SPE and therefore build commands are changed for building regression tests and PSA arch tests. Could you please refer to https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/23898 for updated commands/configuration to integrate NS side and port platforms after build split? If anything is broken after build split, please let us know. It would be also appreciated if you could contribute to build split. 😊 Any feedback or comment is welcome. Best regards, Hu Ziji

2 years, 4 months

1
1
0 0

How is Secure Enclave configured?

by Sunguk Bin

I have a few questions regarding RSS and Secure Enclave to see what's required and considered for SoC design to leverage RSS and why we nee to use RSS & TF-M 1. What is the difference between RSS and Secure Enclave? - Is RSS the same as Secure Enclave? - Or is it referring to any subsystem providing runtime crypto service regardless of whether it's a Secure Enclave or not? Question below is assuming RSS is a Secure Enclave...... 2. What enables TF-M to operate as a Secure Enclave? - To operate as a Secure Enclave, HW support is mandatory? a) If so, we must use a Secure Enclave IP such as cryptoisland(CI-300P-C)? b) Or can we construct a Secure Enclave with some other IPs(LCM, KMU, CryptoCell) metioned RSS doc? (by using TF-M without secure enclave IP) It feels vague whether this can be called a Secure Enclave... https://tf-m-user-guide.trustedfirmware.org/platform/arm/rss/rss_key_manage… - If HW support is not mandatory, I wonder how TF-M can operate as a Secure Enclave. - The article below seems to say that TF-M can provide Secure Enclave functionality without HW support. or I may misunderstand. https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/tfm/technical_re…

2 years, 4 months

2
5
0 0

Non-secure client id management

by Chris.Brand＠infineon.com

Hi, Reading through https://tf-m-user-guide.trustedfirmware.org/integration_guide/non-secure_cl… I'm wondering why so much of the work is done in the secure world. Ultimately, the secure world relies on the non-secure world to tell it the client_id, directly or indirectly. Is there a good reason for the NCSE part to reside in the secure world, rather than the non-secure? Particularly as the document states that the non-secure RTOS may have a built-in "Secure Context Manager", there may well be redundancy between that and NCSE that could be eliminated if the NCSE was in the NSPE. And the less code there is in the secure world, the less scope for vulnerabilities. If client_ids themselves were passed from the NS to the S world, it would probably be very easy to use that same interface on the NS core in a dual core system, too. Chris

2 years, 4 months

2
1
0 0

Bool cast is wrong in Corestone cmake file

by Bohdan.Hunko＠infineon.com

Hi, Seems like following code $<$<BOOL:TFM_PARTITION_PLATFORM>:${CMAKE_CURRENT_SOURCE_DIR}/services/src/tfm_platform_system.c> In platform/ext/target/arm/corstone1000/CMakeLists.txt is wrong because it uses TFM_PARTITION_PLATFORM but should use ${ TFM_PARTITION_PLATFORM } If so then maybe platform maintainers can fix this. 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, 5 months

1
0
0 0

Recommended GNU compiler version

by Quach, Brian

Is 11.2-2022.02 the recommended compiler version? I saw TF-M v1.8 states: " GNU Arm compiler version *10-2020-q4-major* has an issue in CMSE support. The bug is reported in `here <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157>`__. Select other GNU Arm compiler versions instead. GNU Arm compiler version greater and equal than *11.3.Rel1* has a linker issue in syscall. Select other GNU Arm compiler versions instead. " Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years, 5 months

3
8
0 0

gateway attribute question

by Quach, Brian

Hi, When is it appropriate to use "__tz_c_veneer" vs. "__tfm_nspm_secure_gateway_attributes__"? The only difference appears to be placing it in "SFN" section. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years, 5 months

2
1
0 0

Build error with customized mbedcrypto configuration

by S Krishnan, Archanaa

Hello, I am trying to build TF-M v1.8 with a custom tfm_mbedcrypto_config_profile_medium.h . I mainly do not want to use a platform specific calloc /free calls, instead use standard free() and calloc(). If I disable MBEDTLS_PLATFORM_MEMORY and MBEDTLS_PLATFORM_C in tfm_mbedcrypto_config_profile_medium.h and attempt to build TF-M, I get the following error: /arm-none-eabi/lib/thumb/v8-m.main+fp/hard/libnosys.a(sbrk.o): in function `_sbrk': /data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/libgloss/libnosys/sbrk.c:21: undefined reference to `end' I'm able to build mbedtls package with both MBEDTLS_PLATFORM_MEMORY and MBEDTLS_PLATFORM_C disabled without any errors, the undefined reference error is only seen when building TF-M. Any thoughts on how to resolve this? Regards, Archanaa

2 years, 5 months

4
10
0 0

Dependency on generated files is broken

by Bohdan.Hunko＠infineon.com

Hi all, Seems like dependency on generated files is broken. Steps to reproduce: 1. Build any platform at any mode 2. Change any .template file 3. Expected result: 1. New file is generated from the updated .template file Actual result: 1. Generated files step is skipped. My best guess will be that 1ce59292a47b1316e5d8b4d28bcaf9d8e2bdc0a5 broke it. Could this be fixed? 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, 5 months

4
10
0 0

Rename TF-M branches master -> main

by Anton Komlev

Hello, Some time ago we planned to rename our master branch to main in all 6 repositories. There are multiple ways of doing that and I want to discuss with the community the best way suitable for all. I can see the following options: 1. rename master->main and use the main from one day. 2. Create the main for contribution with main->master sync. Make master R/O and delete it in 3 months. 3. Keep contributing to the master but syncing master->main. 4. Other way? I suggest option 2 but looking for better alternatives if any. Thanks, Anton

2 years, 5 months

4
6
0 0

Mailbox agent API doc update - should be the final round

by Ken Liu

Hi everyone, The mailbox ns agent update document has the latest update to solidarize the API, here is the link for your review: Docs: Mailbox non-secure vectors processing (Ie4ec599c) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/22282> The agent-specific API should be good enough for now to handle different mailbox implementation cases, such as memory-based or non-memory-based. * Non-secure provided vectors can be referenced directly to avoid extra copy. * For non-memory-based schemes, the vectors have to be collected locally in NS Agent. We are also updating the code to validate the new API, may touch those platforms that are mailbox-related, please take care of the patches as well. SPM: Update the agent API to follow the design (I38e67578) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/22608/2> BR /Ken

2 years, 5 months

1
0
0 0

New TrustedFirmware Discord Server

by Don Harbin

Hi All, Note you may have received another instance of this note but when I attempted to send to all TF ML's simultaneously it seemed to fail, so sending to each one at a time. Sorry about that. :/ We've created a Discord Server for real time chats/sharing. This solution comes at no cost to the project, is set up with channels for each project, includes a #general channel, and supports direct 1-1 chats between members, all with the goal of improving collaboration between trustedfirmware.org developers. We encourage all to join! :) Instructions for joining can be found on the TF.org FAQ page <https://www.trustedfirmware.org/faq/>. See you all there and please don't hesitate to reach out if you have any questions! Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 6 months

1
0
0 0

New TrustedFirmware Discord Server

by don.harbin＠linaro.org

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

2 years, 6 months

1
0
0 0

Announcing TF-Mv1.8.1 fix

by Anton Komlev

Hi, TF-M released a hotfix to the current version, tagged by TF-Mv1.8.1<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.8…> The fixes: * Partial tag comparison when using Chacha20-Poly1305 on the PSA driver API interface in CryptoCell enabled platforms. Registered as CVE-2023-40271, Please check the related advisory TFMV-6: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/secur… Thanks, Anton

2 years, 6 months

1
0
0 0

Updated invitation: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday (BST) (tf-m@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated TF-M Tech forum Every 4 weeks from 8am to 9am on Thursday United Kingdom Time Location https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9253579… About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==…Topic: TF-M Tech forum - Asia Time Zone FriendlyTime: Nov 12, 2020 07:00 AM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 4, 2021, 5 occurrence(s)        Nov 12, 2020 07:00 AM        Dec 10, 2020 07:00 AM        Jan 7, 2021 07:00 AM        Feb 4, 2021 07:00 AM        Mar 4, 2021 07:00 AMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT09Meeting ID: 925 3579 4925Passcode: 414410One tap mobile+12532158782,,92535794925# US (Tacoma)+13462487799,,92535794925# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 925 3579 4925Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW Guests Don Harbin - creator tf-m(a)lists.trustedfirmware.org anton.komlev(a)arm.com leonardo.sandoval(a)linaro.org abdelmalek.omar1(a)gmail.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Reply for tf-m(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 6 months

1
0
0 0

Updated invitation: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday (BST) (tf-m@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated TF-M Tech forum Every 4 weeks from 8am to 9am on Thursday United Kingdom Time Location https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9253579… About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==…Topic: TF-M Tech forum - Asia Time Zone FriendlyTime: Nov 12, 2020 07:00 AM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 4, 2021, 5 occurrence(s)        Nov 12, 2020 07:00 AM        Dec 10, 2020 07:00 AM        Jan 7, 2021 07:00 AM        Feb 4, 2021 07:00 AM        Mar 4, 2021 07:00 AMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT09Meeting ID: 925 3579 4925Passcode: 414410One tap mobile+12532158782,,92535794925# US (Tacoma)+13462487799,,92535794925# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 925 3579 4925Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW Guests Don Harbin - creator tf-m(a)lists.trustedfirmware.org anton.komlev(a)arm.com leonardo.sandoval(a)linaro.org abdelmalek.omar1(a)gmail.com joanna.farley(a)arm.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Reply for tf-m(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 6 months

1
0
0 0

Updated invitation: TF-M Tech forum @ Every 4 weeks from 4pm to 5pm on Thursday (BST) (tf-m@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated TF-M Tech forum Every 4 weeks from 4pm to 5pm on Thursday United Kingdom Time Location https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9557079… This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==… Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 18, 2021, 6 occurrence(s)        Oct 29, 2020 03:00 PM        Nov 26, 2020 03:00 PM        Dec 24, 2020 03:00 PM        Jan 21, 2021 03:00 PM        Feb 18, 2021 03:00 PM        Mar 18, 2021 03:00 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742# US (Tacoma)+13462487799,,95570795742# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number: https://linaro-org.zoom.us/u/abx3I7IoRq Guests Don Harbin - creator anton.komlev(a)arm.com abdelmalek.omar1(a)gmail.com kevin.townsend(a)linaro.org seth(a)nxmlabs.com leonardo.sandoval(a)linaro.org tf-m(a)lists.trustedfirmware.org joanna.farley(a)arm.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=djczYWZqa3ZmMW5n… Reply for tf-m(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=djczYWZqa3ZmMW5n… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 6 months

1
0
0 0

Updated invitation: TF-M Tech forum @ Every 4 weeks from 3pm to 4pm on Thursday from Thu Jan 20, 2022 to Thu Aug 31 (GMT) (tf-m@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: time TF-M Tech forum Every 4 weeks from 3pm to 4pm on Thursday from Thursday Jan 20, 2022 to Thursday Aug 31 United Kingdom Time Location https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9557079… This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==… Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 18, 2021, 6 occurrence(s)        Oct 29, 2020 03:00 PM        Nov 26, 2020 03:00 PM        Dec 24, 2020 03:00 PM        Jan 21, 2021 03:00 PM        Feb 18, 2021 03:00 PM        Mar 18, 2021 03:00 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742# US (Tacoma)+13462487799,,95570795742# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number: https://linaro-org.zoom.us/u/abx3I7IoRq Guests Don Harbin - creator anton.komlev(a)arm.com abdelmalek.omar1(a)gmail.com kevin.townsend(a)linaro.org seth(a)nxmlabs.com leonardo.sandoval(a)linaro.org tf-m(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=djczYWZqa3ZmMW5n… Reply for tf-m(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=djczYWZqa3ZmMW5n… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 6 months

1
0
0 0

CRYPTO_BUILTIN_KEYS

by Quach, Brian

Hi, I see "CRYPTO_TFM_BUILTIN_KEYS_DRIVER" mentioned in the documentation but where is "CRYPTO_BUILTIN_KEYS" defined? And should those target props be formatted as "${prop}"? target_compile_definitions(tfm_psa_rot_partition_crypto PUBLIC MBEDTLS_PSA_CRYPTO_DRIVERS MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS $<$<BOOL:CRYPTO_BUILTIN_KEYS>:PSA_CRYPTO_DRIVER_TFM_BUILTIN_KEY> PRIVATE $<$<STREQUAL:${CRYPTO_HW_ACCELERATOR_TYPE},cc312>:CRYPTO_HW_ACCELERATOR_CC312> MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER ) https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/… Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years, 6 months

2
2
0 0

PSA Crypto headers for v8-M TrustZone Solution - feedback gathering

by Antonio De Angelis

Hi all, following up on the presentation I gave on last tech forum (https://www.trustedfirmware.org/docs/PSACryptoHeader_June23_Antonio_shareab…) and related discussion (https://linaro-org.zoom.us/rec/share/1bBb9d06OWPACMtT_wC6C336k2Y0oeAtbM5REG… , passcode: *%RuR8Q8), I'd like to start this thread to collect feedback on TF-M's current solution as a candidate for this effort. TF-M's headers: psa « include « interface - trusted-firmware-m.git - Trusted Firmware for M profile Arm CPUs<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/interface/…> I plan to discuss the feedback received in one of the coming tech-forums (but likely not next week's). Thanks, Antonio

2 years, 7 months

2
1
0 0

S/MIME email certificate usage in Mbed TLS library

by nagarajan.rak＠gmail.com

Our requirement is to send email securely from our embedded device running on STM32H7 processor. There's an SMTP client application (implemented using Mbed TLS library) running on this device, which will send emails to the recipient via custom/public email server such as smtp.gmail.com. We are planning to use S/MIME email certificate from the one of the Trusted CA, for encryption of the email message and authentication of the client/server. We learnt that each S/MIME email certificate support only one email address, but we will be having multiple devices running on the field and each device will have unique email address from which email will be sent. Getting S/MIME email certificate for device will not be feasible, is there any better way we can handle this scenario effectively. Your response to this problem is greatly appreciated. Thank you, Nagaraj

2 years, 7 months

2
1
0 0

Hybrid platforms discussion follow up.

by Anton Komlev

Hi, On the last tech forum (June 22) we started discussion on multicore hybrid platforms. By this mail I’d like to follow up and continue offline analyses on new use-cases and requirements for TF-M design update. The recorded session is available here: https://linaro-org.zoom.us/rec/share/yseF-mYwUTtHHPkQJQO6IEv72xCd0Lz1pQQecc…, Passcode: 5s=Npv=w and slides: https://www.trustedfirmware.org/docs/tech_forum_20230622_Hybrid_platforms.p… The current plan is to take time, think on the use-cases and map them on requirements. With more thought and materials, we will have another session about September time to define our needs in the support of new type of platform. Please share your thoughts in reply. Thanks, Anton

2 years, 7 months

3
3
0 0

Design update: Choose ABI for partition interfaces by checking boundaries

by Xinyu Zhang

Hi, We are planning to update the mechanism on partition interface ABI selection in IPC model. In current Implementation, cross call ABI is chosen in Isolation Level 1, and SVC call ABI is chosen in Isolation Level 2&3. However, interfaces are actually the bridge between SPM and caller partitions. If one partition shares the same boundary with SPM, cross call ABI is the choice; while if one partition does not share the same boundary with SPM, a SVC ABI is the proper choice. But, a simple comparison between two boundary values cannot be used for checking if the two boundaries are the same one - these values might be encoded with bit fields and contains more info than memory regions. Hence the comparison should be done by who generated them - the isolation HAL implementation in platform sources. So here comes to the following design: 1. In HAL function tfm_hal_bind_boundary, encode p_ldinf into boundary value, so that there is no need to pass both p_ldinf and boundary value to switch boundary. 1. Implement a HAL function to compare boundaries and switch boundary if needed. tfm_hal_status_t tfm_hal_switch_boundary( uintptr_t target_boundary, uintptr _t current_boundary, uint32_t compare_only, /* 0: Switch boundary if they are different, 1: Only compare whether the boundaries are different and do not switch */ uint32_t* compare_result); /* Tell the caller whether the boundaries are different */ 1. Select correct type of ABI when processing metadata of partition based on boundary. void prv_process_metadata(struct partition_t *p_pt) { ... tfm_hal_switch_boundary(SPM_BOUNDARY, p_pt->boundary, 1, *compare_result); if (compare_result == 1) { p_rt_meta->psa_fns = &psa_api_svc; } else { p_rt_meta->psa_fns = &psa_api_cross; } ... } Please let us know if you have any suggestion. Thanks, Xinyu

2 years, 8 months

1
0
0 0

FYI: Session on OpenCI and MISRA

by Don Harbin

Hi All, I wanted to let you know that next Thursday, July 27th, the TF-A Tech Forum will be hosting a presentation on OpenCI and MISRA presented by Paul Sokolovski of Linaro and Roberto Bagnara from Bugseng. MISRA is being enabled on both TF-A and TF-M in OpenCI, so sending this out to both lists since users in both domains may be interested in the session. Meeting time and dial up info can be found in the TF community calendar located here: https://www.trustedfirmware.org/meetings/ Best Regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 8 months

1
0
0 0

Why client API is built with tfm_sprt target?

by Roman.Mazurak＠infineon.com

Hi all, I'm wondering why client API is build with tfm_sprt target (Secure Partition Runtime Library)? Client API is used by non-secure clients and secure clients. It means that static library is built once, but used with two different images. And it's expected that such images can use different types of cores, compilation settings, etc... Probably it make sense to build this target in scope of psa_interface. Regards, Roman.

2 years, 8 months

3
3
0 0

mbedtls_platform_setup/teardown in TF-M ?

by Rehan Malak

Dear TF-M developers, I am currently adapting a basic MbedTLS / PSA Crypto example such that it would run on the NS side with TF-M doing the crypto. At the end, this is very similar to this psa_sign_verify_message_test from the NS crypto test suite : https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/sui… But my build config of MbedTLS has MBEDTLS_PLATFORM_SETUP_TEARDOWN_ALT enabled because I have a custom mbedtls_platform_setup / mbedtls_platform_teardown. And I can't see any place in TF-M where mbedtls_platform_setup/mbedtls_platform_teardown are called : ? -> mbedtls_platform_setup ? -> mbedtls_platform_teardown At first, I tried to put this code into the psa_driver_wrapper_init/psa_driver_wrapper_free but I have a similar problem : tfm_crypto_engine_init -> psa_crypto_init -> psa_driver_wrapper_init ? -> mbedtls_psa_crypto_free -> psa_driver_wrapper_free Is there any cmake/Kconfig option or any C macros to hook TF-M initialization/shutdown with mbedtls_platform_setup/mbedtls_platform_teardown without patching TF-M ? If not, could mbedtls_platform_setup be called here ? https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/… or is there a nicer way of doing this ? (btw, I am currently experimenting on qemu mps2-an521) Thanks for any advice ! 🙂 Best regards, Rehan MALAK Intrinsic ID

2 years, 8 months

4
4
0 0

Configuration order

by Roman.Mazurak＠infineon.com

Hi Andrey, Patch 21339<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/21339> introduced changes of configuration order: 1. Platform configuration via TARGET_CONFIG_HEADER_FILE. 2. Project configuration via PROJECT_CONFIG_HEADER_FILE 3. config_base.h It means that target can't change configuration that is expected to be changed by project. Example: 1. Platform must redefine ITS_STACK_SIZE to satisfy driver requirements. The good way for this is to set ITS_STACK_SIZE in config_tfm_target.h. 2. Project developer need to perform some additional debugging or profiling of the product, so the TF-M must be built with extra code that require additional stack size. It means that project developer need to #undef ITS_STACK_SIZE and then redefine it using #define ITS_STACK_SIZE. But this #undef/#define approach is not safe, because it's possible to calculate some other settings using configuration variable in config_tfm_target.h or perform additional configuration validation by config_tfm_target.h. It looks like the new changes created another bunch of problems for TF-M configuration. Regards, Roman.

2 years, 8 months

2
1
0 0

Fwd: [Tf-openci-triage] FYI; Cambridge Lab Down

by Don Harbin

FYI to all TF dev teams leveraging Open CI. Best regards, Don ---------- Forwarded message --------- From: Glen Valante via Tf-openci-triage < tf-openci-triage(a)lists.trustedfirmware.org> Date: Fri, 23 Jun 2023 at 08:41 Subject: [Tf-openci-triage] FYI; Cambridge Lab Down To: tf-openci-triage(a)lists.trustedfirmware.org < tf-openci-triage(a)lists.trustedfirmware.org> Hello All; FYI; the Cambridge lab took a serious power hit and is down. They are scrambling to get things back up, but it may take all weekend. Expect LAVA failures and other strange results. Thanks; -g -- [image: Linaro] <http://www.linaro.org> Glen Valante | *Director Program & Project Management* T: +1.508.517.3461 <1617-320-5000> glen.valante(a)linaro.org | Skype: gvalante <callto:gvalante> -- Tf-openci-triage mailing list -- tf-openci-triage(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-triage-leave(a)lists.trustedfirmware.org

2 years, 8 months

1
0
0 0

ST support for secure peripheral partition

by Spinnler, Christian

Hi all, I am currently trying out TF-M together with Zephyr and therefore ported it to the Nucleo-U575ZI-Q evaluation board. I started to struggle when trying to implement an example for a custom Secure Partition (SP) which should access peripherals. I recognized, that the `target_cfg.*` throughout different vendors follow different design principles. E.g. for Nordic controllers an example is given with their nordic-sdk on how to implement peripheral access for a SP (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/nrf/samples/tfm/…). For ST devices I tried to transfer this, however, where unsuccessful so far as for the ST microcontrollers the peripheral definitions are missing, and things are just different. Is there any example for ST controllers on how to make specific peripherals only accessible through SPE? Is this currently supported for ST devices? And another question, as the Embedded Open Source Summit arises, is TF-M represented somewhere on conferences? Kind Regards Christian Spinnler Siemens AG Technology Connectivity & Edge T CED SSI-DE Schuckertstrasse 2 91058 Erlangen, Deutschland mailto:christian.spinnler@siemens.com www.siemens.com<https://siemens.com> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Roland Busch, Vorsitzender; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin-Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322

2 years, 9 months

4
4
0 0

ARMCLANG protections bug

by Bohdan.Hunko＠infineon.com

Hi all, In GCC linker scripts ands of sections are aligned using following syntax: . = ALIGN(TFM_LINKER_XXX_ALIGNMENT); But in ARMClang TFM does not use similar approach, instead it creates Position tags sections like following: TFM_APP_CODE_START +0 ALIGN TFM_LINKER_APP_ROT_LINKER_CODE_ALIGNMENT EMPTY 0x0 { } TFM_APP_ROT_LINKER +0 ALIGN TFM_LINKER_APP_ROT_LINKER_CODE_ALIGNMENT { *tfm_app_rot_partition* (+RO-CODE, +RO-DATA) *libplatform_s* (TFM_*_APP-ROT_ATTR_FN) *.o (TFM_*_APP-ROT_ATTR_FN) } /* * This empty, zero long execution region is here to mark the end address * of APP RoT code. */ TFM_APP_CODE_END +0 ALIGN TFM_LINKER_APP_ROT_LINKER_CODE_ALIGNMENT EMPTY 0x0 { } I believe this is done because clang does not have syntaxes for aligning end of the section (please correct me if I am wrong). This approach results in bug in TFM_UNPRIV_CODE section protections, because TFM_UNPRIV_CODE Base and Limit are used directly and Limit is not aligned. For now this problem stayed undetected because present platforms does not validate region_limit when applying protections. I have created this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/21169> , which adds validation of region_limit and ran Ci on it and I can see that CI failed in tests for Clang builds So I guess this is the problem that have to be fixed. I see following possible solutions: 1. Align and of TFM_UNPRIV_CODE section (but I guess clang does not support that) 2. Add position tags for _START and END Solution 1 will simpler as it will not require changed in platform code, but I guess clang syntaxes is limiting us here. So my question would be whether there is a plan to fix this issue ? 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, 9 months

2
2
0 0

TFM Corstone1000 Cmake Error

by 박진국

Hi all. I am trying to port TFM using the corstone1000 platform. Previously, I was using the 1.7.0 version. TFM version was recently updated and I am trying to use the 1.8.0 version by downloading it from the site below. https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git As instructed by the site below ( https://tf-m-user-guide.trustedfirmware.org/platform/arm/corstone1000/readm… ) I executed the command below. cmake -B build/ -S . -DCMAKE_BUILD_TYPE=Debug -DTFM_TOOLCHAIN_FILE=<tf-m-root>/toolchain_GNUARM. cmake -DTFM_PLATFORM=arm/corstone1000 -DTEST_NS=OFF -DTEST_S=ON -DTEST_S_PS=OFF -DTEST_S_PLATFORM=OFF -DEXTRA_S_TEST_SUITE_PATH=platform/ext/target/arm/corstone1000/ci_regression_tests/ However, I got a cmake error as shown below. - Build type: Debug -- Host: Linux/x86_64 -- Target: Generic/arm -- Machine: template -- Host: Linux/x86_64 -- Target: Generic/arm -- Machine: template -- C_FLAGS : -mcpu=cortex-m0plus -Wall -Wextra CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:144 (target_sources): Cannot specify sources for target "platform_bl1" which is not built by this project. CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:168 (target_compile_definitions): Cannot specify compile definitions for target "platform_bl1" which is not built by this project. CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:175 (target_include_directories): Cannot specify include directories for target "platform_bl1_interface" which is not built by this project. I think this is caused by the target for platform_bl1 not being specified, but I don't know how to fix it. I executed cmake using the same configuration as set in corstone1000's config.cmake. Can anyone tell me why I am getting the above error? Any advice would be very helpful. thanks you.

2 years, 9 months

4
4
0 0

TFM Corstone1000 Cmake Error

by 박진국

Hi all. I am trying to port TFM using the corstone1000 platform. Previously, I was using the 1.7.0 version.  TFM version was recently updated and I am trying to use the 1.8.0 version by downloading it from the site below. https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git As instructed by the site below  (https://tf-m-user-guide.trustedfirmware.org/platform/arm/corstone1000/readm…) I executed the command below. cmake -B build/ -S . -DCMAKE_BUILD_TYPE=Debug -DTFM_TOOLCHAIN_FILE=<tf-m-root>/toolchain_GNUARM. cmake -DTFM_PLATFORM=arm/corstone1000 -DTEST_NS=OFF -DTEST_S=ON -DTEST_S_PS=OFF -DTEST_S_PLATFORM=OFF -DEXTRA_S_TEST_SUITE_PATH=platform/ext/target/arm/corstone1000/ci_regression_tests/ However, I got a cmake error as shown below. - Build type: Debug -- Host: Linux/x86_64 -- Target: Generic/arm -- Machine: template -- Host: Linux/x86_64 -- Target: Generic/arm -- Machine: template -- C_FLAGS : -mcpu=cortex-m0plus -Wall -Wextra CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:144 (target_sources):   Cannot specify sources for target "platform_bl1" which is not built by this   project. CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:168 (target_compile_definitions):   Cannot specify compile definitions for target "platform_bl1" which is not   built by this project. CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:175 (target_include_directories):   Cannot specify include directories for target "platform_bl1_interface"   which is not built by this project. I think this is caused by the target for platform_bl1 not being specified, but I don't know how to fix it. I executed cmake using the same configuration as set in corstone1000's config.cmake. Can anyone tell me why I am getting the above error? Any advice would be very helpful. thanks you.

2 years, 9 months

1
0
0 0

TFM Corstone1000 Cmake Error

by 박진국

Hi all. I am trying to port TFM using the corstone1000 platform. Previously, I was using the 1.7.0 version.  TFM version was recently updated and I am trying to use the 1.8.0 version by downloading it from the site below. https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git As instructed by the site below  (https://tf-m-user-guide.trustedfirmware.org/platform/arm/corstone1000/readm…) I executed the command below. cmake -B build/ -S . -DCMAKE_BUILD_TYPE=Debug -DTFM_TOOLCHAIN_FILE=<tf-m-root>/toolchain_GNUARM. cmake -DTFM_PLATFORM=arm/corstone1000 -DTEST_NS=OFF -DTEST_S=ON -DTEST_S_PS=OFF -DTEST_S_PLATFORM=OFF -DEXTRA_S_TEST_SUITE_PATH=platform/ext/target/arm/corstone1000/ci_regression_tests/ However, I got a cmake error as shown below. - Build type: Debug -- Host: Linux/x86_64 -- Target: Generic/arm -- Machine: template -- Host: Linux/x86_64 -- Target: Generic/arm -- Machine: template -- C_FLAGS : -mcpu=cortex-m0plus -Wall -Wextra CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:144 (target_sources):   Cannot specify sources for target "platform_bl1" which is not built by this   project. CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:168 (target_compile_definitions):   Cannot specify compile definitions for target "platform_bl1" which is not   built by this project. CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:175 (target_include_directories):   Cannot specify include directories for target "platform_bl1_interface"   which is not built by this project. I think this is caused by the target for platform_bl1 not being specified, but I don't know how to fix it. I executed cmake using the same configuration as set in corstone1000's config.cmake. Can anyone tell me why I am getting the above error? Any advice would be very helpful. thanks you.

2 years, 9 months

1
0
0 0

Using bitwise or (|) / and (&) in Clang scatter file

by Bohdan.Hunko＠infineon.com

Hi For our platform we use some ,across which should set/clear bit 28 of an address (see code below). We do this for convenience reasons. #define IFX_S_ADDRESS_ALIAS(x) ((x) | 0x10000000) #define IFX_NS_ADDRESS_ALIAS(x) ((x) & ~0x10000000) Those macros are used in declaration of S_CODE_START macro. When expended in linker script (tfm_isolation_l3.o), the declaration of LR_CODE section looks as follows: LR_CODE (0x24000000 | 0x10000000) (0x4B000) { This code results in following error: tfm_isolation_l3.o", line 46 (column 21): Error: L6292E: Ignoring unknown attribute '|' specified for region LR_CODE. I tried experimenting with this and found out that when | is changed to or (see following code) then linker works fine: LR_CODE (0x24000000 or 0x10000000) (0x4B000) { Same problem is present when using bitwise and (&). But when using bitwise NOT (~0x...) everything works fine. Having to define our macros in different way brings some problems for our platform, so maybe someone knows how to solve this problem? Maybe there are compilation flags or something like that? Ideally we want | and & to work fine in linker script. Thanks! 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, 9 months

2
2
0 0

Trying to debug TF-M across NS/S boundary

by Lena Boeckmann

Hi! I found the e-mail below from 2020 and this is exactly where I'm at right now: I have a Zephyr application with TF-M flashed on an nrf9160dk and managed to open a debugging session following the explanation here: https://tf-m-user-guide.trustedfirmware.org/platform/nxp/lpcxpresso55s69/RE… (might be good to mention in the documentation that this also works on other platforms or have a general "Debug with GDB section"). So far I can either debug the secure image or or the non-secure image, but I would actually like to see the communication between the two. Is it even possible to debug across the boundary? I'm not very experienced in using GDB (except for the basics). Is there some kind of TF-M specific tutorial or explanation by now? Or is there anyone who can give me a hint on how to do this? Kind regards, Lena Kevin Townsend wrote: > Hi Anton, > One particular difficulty I've encountered working with TF-M for the Zephyr > certification demo app, and with the LPC55S69 port to upstream TF-M is the > debugging experience with GDB and the dual execution environments. GDB can > be quite powerful if you are familiar with it, but there is a definite > learning curve, and the S and NS separation and the dual binary images > (three with BL2) adds an additional degree of complexity. > I think having a dedicated debugging tutorial around GDB would be very > useful to people adopting TF-M and perhaps new to GDB, just to show how > some basic debugging might happen, how to debug across the NS/S boundary, > etc. > For example, the '--tui' option for GDB may not be very well known, and it > may be useful to highlight (see screenshots at the bottom of this issue: > https://github.com/microbuilder/trusted-firmware-m/issues/1) > Practical, step-by-step debugging documentation just seems like a good > investment to help flatten this inevitable learning curve developing > real-world solutions with TF-M? > Best regards, > Kevin > On Thu, 27 Feb 2020 at 13:13, Anton Komlev via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > > A kind reminder. > > Your feedback is valuable all the time with no deadline defined. > > *From:* TF-M tf-m-bounces(a)lists.trustedfirmware.org * On Behalf Of *Anton > > Komlev via TF-M > > *Sent:* 07 February 2020 13:13 > > *To:* tf-m(a)lists.trustedfirmware.org > > *Cc:* nd nd(a)arm.com > > *Subject:* [TF-M] Call for a feedback on TF-M adaptation experience > > Dear All, > > As I mentioned on yesterday’s call, there is a concern on user experience > > related to TF-M use. > > To In order to understand and potentially improve it I am looking for a > > voice of partners who adopted TF-M project. > > Please share your experience and thoughts on parts which are good or might > > be done better to simplify TF-M integration with your project. > > You feedback will be very appreciated in any form – as a response to this > > mail or as a direct mail to me (anton.komlev(a)arm.com) if it’s more > > comfortable for you. > > Thank you in advance, > > Anton > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > >

2 years, 9 months

2
1
0 0

Branch release/1.7.x to be deleted

by Anton Komlev

Hi, I plan to delete the branch release/1.7.x at the end of this week (after May 26) following TF-M release process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Please let me know if someone is dependent on it and needs more time to detach from it. Thanks, Anton

2 years, 10 months

1
0
0 0

psa_call performance

by Quach, Brian

Hi, Using isolation level 1 and IPC secure partition, I noticed psa_call() overhead for TFM v1.7 is significantly worse for than v1.1. Is this expected? Assuming 1 invec and 0 outvec for the PSA call.... TF-M version Psa_call() round trip cycles v1.1 4038 v1.7 6051 Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years, 10 months

6
16
0 0

Querying Anyone Using Shared Memory to Share Lifecycle, Bootseed, Hardwareversion Info

by Sherry Zhang

Hi, Currently in the Attestation partition, when encoding the security lifecycle, boot seed, and hardware version claims, these info are searched in the shared memory firstly before calling the platform hal APIs. See the code here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>. Sharing this information via shared memory is a legacy mechanism and MCUboot does not writes that information when booting. And calling the platform hal APIs way is recommended. I created this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/21021> removes looking for the security lifecycle, boot seed, and hardware version from shared memory. Before opening this patch for review, I would like to query whether this mechanism is being used by any platform. Is there any platform(which suppose runs a bootloader which is not MCUboot) using this sharing memory mechanism to provide the security lifecycle, boot seed, and hardware version information now? Thanks, Regards, Sherry Zhang

2 years, 10 months

1
0
0 0

Split build

by Bohdan.Hunko＠infineon.com

Hi everyone, Some time ago patch for split build<https://review.trustedfirmware.org/q/topic:%2522split-build%2522> of SPE, NSPE, BL2 was announced. I am interested on when this patch is planned to be merged? 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, 10 months

4
5
0 0

How to solve the link error while enable both mbedTLS and TF-M crypto interfaces in NSPE

by Edward Yang

Hi experts, Recently we're developing an example demo based on TF-M, the application scenario is simplified as below. MbedTLS module in NSPE is used to guarantee the secure communication with AWS cloud, while TF-M in SPE provides data encryption/decryption and sensitive data storage services. So both TF-M interfaces and mbedtls module are enabled on NSPE, there will be two implementations of PSA Crypto and this will result in a link error. The red box displays files with conflicts between mbedtls and TF-M, which prevent the project from compiling. Can all TF-M code be converted into a lib to avoid linking issues? Or is there any other way to solve this problem? Best Regards, Poppy Wu http://www.mxic.com.cn

2 years, 10 months

5
6
0 0

Re: [tfm_test_repo]why should the sha_1 not be supported at secure test suite

by zhilei.wang＠bekencorp.com

Hi, Antonio, Get it. Thank you very much Best Regards zhilei.wang | bekencorp From: Antonio De Angelis via TF-M Date: 2023-05-11 20:35 To: tf-m CC: nd Subject: [TF-M] Re: [tfm_test_repo]why should the sha_1 not be supported at secure test suite Hi Zhilei, The configuration of the TF-M Crypto service that it’s tested by default is just an example, and the SHA-1 algorithm is allowed from the PSA spec point of view; in our case we have decided to not enable SHA-1 support due to the fact that it’s widely accepted to have known collision attacks [1], NIST deprecating it in 2011 [2], and having exposed weaknesses since long, 2005 [3], i.e. to encourage by default having a look into more robust alternatives. Anyway, TF-M’s test 1010 just aims at testing the interface for the correct error response, nothing more. If your deployment still supports PSA_ALG_SHA_1, I’d recommend to just ignore the output of TEST_1010. On our side, we could gate the test not to run when PSA_WANT_ALG_SHA_1 is defined. Thanks, Antonio [1] SHAttered [2] NIST Retires SHA-1 Cryptographic Algorithm | NIST [3] 010.pdf (iacr.org) From: zhilei.wang(a)bekencorp.com <zhilei.wang(a)bekencorp.com> Sent: Thursday, May 11, 2023 13:44 To: tf-m <tf-m(a)lists.trustedfirmware.org> Cc: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; Summer Qin <Summer.Qin(a)arm.com>; poppywu <poppywu(a)mxic.com.cn> Subject: [tfm_test_repo]why should the sha_1 not be supported at secure test suite Hi, Why should the sha_1 not be supported at secure test suite? Our soc has a cypto accelerator, that supports sha_1/224 and so on. The following is the detail. File: \tfm\lib\ext\tfm_test_repo-src\test\secure_fw\suites\crypto\secure\crypto_sec_interface_testsuite.c Function: static void tfm_crypto_test_1010(struct test_result_t *ret) { psa_unsupported_hash_test(PSA_ALG_SHA_1, ret); } Thanks and best regards, zhilei.wang bekencorp

2 years, 10 months

1
0
0 0

[tfm_test_repo]why should the sha_1 not be supported at secure test suite

by zhilei.wang＠bekencorp.com

Hi, Why should the sha_1 not be supported at secure test suite? Our soc has a cypto accelerator, that supports sha_1/224 and so on. The following is the detail. File: \tfm\lib\ext\tfm_test_repo-src\test\secure_fw\suites\crypto\secure\crypto_sec_interface_testsuite.c Function: static void tfm_crypto_test_1010(struct test_result_t *ret) { psa_unsupported_hash_test(PSA_ALG_SHA_1, ret); } Thanks and best regards, zhilei.wang bekencorp

2 years, 10 months

2
1
0 0

TF-M Confidential AI presentation next tech forum?

by Kevin Townsend

Hi, I'd like to propose presenting some of the work we've done around "Confidential AI" with TF-M and Zephyr during the next TF Tech Forum call. I think I'll probably need 30 minutes or so, and can take some questions after time and agenda permitting. If you're not familiar with the project, it's an attempt at trying to determine how open standards and open source software (Zephyr, TF-M, MCUBoot, etc.) can be used together in a practical, end-to-end security use case ... in this case, running inference on sensor data in the secure partition, and transmitting sensitive data from S to NS to the cloud. Relevant repos are here, but of course I'll try to give a meaningful overview of all of this during the call since the project has several related components: - https://github.com/Linaro/zephyr_confidential_ai - https://github.com/Linaro/lite_bootstrap_server Thanks and best regards, Kevin Townsend Tech Lead - LITE, Vertical Technologies Linaro.org │ Open source software for ARM SoCs

2 years, 10 months

1
0
0 0

SP FPU config

by Quach, Brian

Hi, Is it correct that CONFIG_TFM_FP_ARCH_ASM is 'empty string' when using FP_ARCH_FPV5_SP_D16? I'm wondering if it should be set to "FPv5-SP" ############################## FP Arch ######################################### config FP_ARCH_FPV5_D16 def_bool n help FPv5-D16 config FP_ARCH_FPV5_SP_D16 def_bool n help FPv5-SP-D16 config CONFIG_TFM_FP_ARCH string default "fpv5-d16" if FP_ARCH_FPV5_D16 default "fpv5-sp-d16" if FP_ARCH_FPV5_SP_D16 default "" config CONFIG_TFM_FP_ARCH_ASM string default "FPv5_D16" if FP_ARCH_FPV5_D16 default "" Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

2 years, 10 months

2
1
0 0

Release v1.8.0 changes are merged.

by Anton Komlev

Hello, The changes made for the TF-M v1.8.0 are merged back to the master branch. To allow that, Corstone-1000 platform was temporarily excluded from OpenCI tests because the platform changes in the release branch conflicted with changes in the master, made in parallel. The platform will be back under test immediately after the conflict resolution. Corstone-1000 platform builds and runs correctly under v1.8.0 tag. Thanks, Anton

2 years, 10 months

1
0
0 0

TF-M release v1.8.0 announcement

by Anton Komlev

Hello, I am pleased to announce the release of TF-M v1.8.0<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.8…>. New major features are: * TF-M eRPC Test framework 1 is integrated. * TF-M builtin key loader integration is reworked. * Improved crypto library abstraction from TF-M Crypto service. * Kconfig system is enhanced and finalized. * Switch to upstream QCBOR 2. * Enable PSA Authenticated Debug Access Control (ADAC) 3 support on Musca-B1 platform. * Support Floating-Point (FP) with Arm Compiler. * FF-M API uses signals to drive the partition scheduling instead of controlling partition context directly. * MCUboot upgrade to v1.10.0. * Mbed TLS upgrade to v3.4.0. * Refine documentation restructure. * It is optional to update copyright year in changes. Requirements of copyright note update is updated in Contributing Process. Please check the release notes<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/relea…> 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, 10 months

1
0
0 0

SVC handlers refining

by Ken Liu

Hello, For isolation levels > 1, partitions need to SVC for PSA APIs. To improve the efficiency of this call type, the SVC handler needs to be simplified. Currently, there are several obvious places to be improved: - Handlers in C have multiple-level function calling; - There are a couple of checks in the handler routine that can be refined. And, to take advantage of instruction TBB, the switch/case number needs to be linear - but it is not always stable hence needs to investigate if a handmade function table would be more stable. The leading patches are here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20644 Feel free to comment or reply in this thread. Thanks. /Ken

2 years, 10 months

1
0
0 0

Adjustments for SVC number assignments that impact platforms with platform-specific SVC

by Kevin Peng

Hi, We're making some adjustments for the SVC number assignments. I'd like to collect some feedbacks, especially from downstream platforms that have your own SVC handler because corresponding changes of your SVC numbers are required when these changes were accepted. Originally, The SVC numbers are categorized by their values, for example, numbers less than 0x40 are PSA API requests and numbers larger than 0x80 are for handler mode. This is not convenient for adding new SVC because it's not intuitive to find a proper value range. More importantly, it's easy to create clashes between TF-M and platform SVC by mistake as they are defined in different files. So, we propose to divide the SVC number bits into different fields for distinguishing different types of SVC. Please see here<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20644/1/secu…> for the detailed descriptions. With these changes, it's much easier to put the SVC numbers in the right range and avoid duplications after setting the bit fields to right values. Thanks, Kevin

2 years, 11 months

1
0
0 0

ITS cmake

by Quach, Brian

Is the highlighted line below correct? Or should the angle bracket be at the end like this: $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/../protected_storage> target_include_directories(tfm_psa_rot_partition_its PRIVATE $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> ${CMAKE_BINARY_DIR}/generated/secure_fw/partitions/internal_trusted_storage PUBLIC # Required for ps_object_defs.h $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>/../protected_storage ) Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

2 years, 11 months

2
1
0 0

PSA Crypto platform specific extensions

by Roman.Mazurak＠infineon.com

Hello everyone, I need to extend PSA Crypto API by adding a platform specific encryption algorithm/key attribute. For example a vendor specific algorithm named ABC must be added. So, I need that following macro must be included when psa/crypto.h is included. #define PSA_ALG_ABC ((psa_algorithm_t) 0x08000123) TF-M provides PSA Crypto interface through includes located in interface/include/psa/crypto*.h. It means that we need to extend TF-M by allowing platform to provide some platform specific crypto header that will be installed in interface folder and included by psa/crypto.h. 1. Is there any activity related to this problem? 2. I'm considering to create a new crypto_config.h that must be generated during build process and which can optionally provide a macro TFM_PLATFORM_CRYPTO_EXTRA. These macro will be used in psa/crypto.h to conditionally include crypto_platform.h - header provided by platform. Thanks, Roman.

2 years, 11 months

2
1
0 0

Start of TF-M v1.8.0 release

by Anton Komlev

Hello, The branch release/1.8.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=release/…> has been created indicating the start of the release process and features freeze. RC1 tag will follow after a successful run of the basic tests. Let me remind that the code is not frozen, and development can be continued on the main branch as described in TF-M Release Process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Thanks, Anton

2 years, 11 months

2
3
0 0

Request for Review: Add platform specific default UART configurations

by Andersson, Joakim

Hi. We at Nordic are running the TF-M regression and PSA architecture tests on our boards, and we get occasional issues with test output because HW flow control is by default disabled in CMSIS. To enable HW flow control in the TF-M we must change the call to the CMSIS UART driver. I've created a change to allows the platform to set any non-default CMSIS configuration, such as HW flow control: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20374 I'd like to ask all platform maintainers to review this change. This change must add another define to all supported platforms, the change itself should not cause any difference in actual behavior. This can be used for other non-default UART configuration in other platforms as well. -Joakim Andersson

2 years, 11 months

1
0
0 0

Support of MCUBOOT_IMAGE_NUMBER > 2

by Bohdan.Hunko＠infineon.com

Hi all, PSA FWU API update to version 1.0 made it easy to support updates of more than 2 images. To do so platform may define its own FWU_DEVICE_CONFIG_FILE which will contain definitions for all the components. So it looks like in current implementation FWU service should easily support FWU_COMPONENT_NUMBER > 2 (for example FWU_COMPONENT_NUMBER = 4) The only place that I see that doesn't support this is secure_fw/partitions/firmware_update/bootloader/mcuboot/tfm_mcuboot_fwu.c file which have following code: #if (MCUBOOT_IMAGE_NUMBER == 1) #define MAX_IMAGE_INFO_LENGTH (sizeof(struct image_version) + \ SHARED_DATA_ENTRY_HEADER_SIZE) #else #define MAX_IMAGE_INFO_LENGTH 2 * (sizeof(struct image_version) + \ SHARED_DATA_ENTRY_HEADER_SIZE) #endif So if MCUBOOT_IMAGE_NUMBER is 4 then MAX_IMAGE_INFO_LENGTH will only account for 2 images. To fix this I propose to change the code to: #define MAX_IMAGE_INFO_LENGTH MCUBOOT_IMAGE_NUMBER * (sizeof(struct image_version) + \ SHARED_DATA_ENTRY_HEADER_SIZE) This change will allow platform to support update of more than 2 components (assuming that platforms implementation of bootloader supports that) So I have few questions: 1. Will such change be accepted upstream? Do you see any problems with this change?\ 2. Are there already platforms that support update of more than 2 components? 3. Are there any known problems with supporting update of more than 2 components? 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, 11 months

2
2
0 0

[RFC] Updated mailbox agent API documents

by Ken Liu

Hi, The mailbox agent API was proposed before and this time more implementation details are introduced in the document: Docs: Implementation details for Mailbox Agent API (Ifec409eb) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20421> Feel free to comment, and feel free to create implementations for it - remember response to this thread before you do. Thanks. /Ken

2 years, 11 months

1
0
0 0

s_veneers linking problem when building uboot with flags -pie

by xulu＠allwinnertech.com

Hi experts, Recently we are building uboot with s_veneers.o, and found that we can not jump to tfm. The reason is that the jump addr is wrong when compileing with -pie. The symbol "tfm_vendor_aes_encrypt_with_hardware_ssk" in s_veneers.o. $ nm ./drivers/tfm/lib/s_veneers.o | grep tfm_vendor_aes_encrypt_with_hardware_ssk 04008029 A tfm_vendor_aes_encrypt_with_hardware_ssk Building uboot without cflags -pie, and the last line shows the wrong jump addr 0xf7fc7e61 0c0401f0 <__tfm_vendor_efuse_write_veneer>: c0401f0: b401 push {r0} c0401f2: 4802 ldr r0, [pc, #8] ; (c0401fc <__tfm_vendor_efuse_write_veneer+0xc>) c0401f4: 46fc mov ip, pc c0401f6: 4484 add ip, r0 c0401f8: bc01 pop {r0} c0401fa: 4760 bx ip c0401fc: f7fc7e61 .word 0xf7fc7e61 Building uboot without cflags -pie，and the last line shows the right jump addr 0x04008029. 0c040200 <__tfm_vendor_aes_encrypt_with_hardware_ssk_veneer>: c040200: b401 push {r0} c040202: 4802 ldr r0, [pc, #8] ; (c04020c <__tfm_vendor_aes_encrypt_with_hardware_ssk_veneer+0xc>) c040204: 4684 mov ip, r0 c040206: bc01 pop {r0} c040208: 4760 bx ip c04020a: bf00 nop c04020c: 04008029 .word 0x04008029 The linker flag -pie is default enabled in uboot(for relocation feature), and we need this feature. Could you please give us some pointers, suggestions or objections about this problem, Thanks!

2 years, 11 months

2
1
0 0

Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation test

by Edward Yang

Hi Antonio, Thank you for taking the time to help confirm the function, and we've found out that this error just resulted from the incorrect initialization of 'operation' before calling PSA APIs, after fixing this bug, we also got the correct OKM. Thanks again for your support. Best Regards, Poppy Wu 吴偏偏 http://www.mxic.com.cn Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> 2023/03/23 21:58 Please respond to Antonio De Angelis <Antonio.DeAngelis(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject [TF-M] Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation test Hi, I have tried the example below on mbed TLS running on an x86 Linux based host machine, and on the AN521 platform, and in both cases I can get consistent results, i.e. the value of the okm buffer at the end is: 0x3c, 0xb2, 0x5f, 0x25, 0xfa, 0xac, 0xd5, 0x7a, 0x90, 0x43, 0x4f, 0x64, 0xd0, 0x36, 0x2f, 0x2a, 0x2d, 0x2d, 0x0a, 0x90, 0xcf, 0x1a, 0x5a, 0x4c, 0x5d, 0xb0, 0x2d, 0x56, 0xec, 0xc4, 0xc5, 0xbf, 0x34, 0x00, 0x72, 0x08, 0xd5, 0xb8, 0x87, 0x18, 0x58, 0x65 Which I believe matches the expected output below. Given that your issue seems to be specific to the stm32l562e_dk platform, which uses its own crypto accelerator I believe rather than pure software implementation, I would suggest to have a look at the intermediate steps and compare your results against the AN521 platform results. You might want to raise this behaviour to the platform maintainer, as at this stage this seems to me to be a platform specific issue. I can only confirm that you are not misusing the PSA Crypto APIs here. Let me know if I can be of any more help. Thanks, Antonio From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, March 23, 2023 12:51 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation test I am going to have a look into this. Thanks for the instructions on how to reproduce. Might get a while to reply, please bear with me. Thanks, Antonio From: Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, March 23, 2023 01:36 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Please help check the failure of PSA_ALG_HKDF_EXPAND operation test Hi experts, Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on stm32l562e_dk platform. But the HKDF-EXPAND output didn't match the expected OKM. The test vector is as below: ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256), "info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"), "L" : 42, "PRK" : "077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5" "OKM" : "3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865" The corresponding code is as follow： int8_t okm[42]={0}; uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9}; uint8_t ikm[]= { 0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf, 0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63, 0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31, 0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5 }; status = psa_key_derivation_setup(&operation, PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_SECRET, ikm, sizeof(ikm)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_INFO, info, sizeof(info)); status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm) ); The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b 2e 19 18 77 ae, which didn't match the OKM of above test vector. Have we misused the HKDF-EXPAND operation? Best Regards, Poppy Wu 吴偏偏 http://www.mxic.com.cn -- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org

2 years, 11 months

1
0
0 0

How does TF-M deal with the faults originated from NSPE

by Sandeep Tripathy

Hi tf-m experts, I have a fundamental query on v8m trustZone and containability of secure fault and other escalated HardFaults to SPE. With BFHFNMINA set to '0' IIUC that a malicious actor in NSPE can willingly cause fault in SPE ? Is there a way to contain the fault in NS world? Thanks Sandeep

2 years, 12 months

4
5
1 0

Please help check the failure of PSA_ALG_HKDF_EXPAND operation test

by Edward Yang

Hi experts, Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on stm32l562e_dk platform. But the HKDF-EXPAND output didn't match the expected OKM. The test vector is as below: ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256), "info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"), "L" : 42, "PRK" : "077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5" "OKM" : "3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865" The corresponding code is as follow： int8_t okm[42]={0}; uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9}; uint8_t ikm[]= { 0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf, 0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63, 0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31, 0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5 }; status = psa_key_derivation_setup(&operation, PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_SECRET, ikm, sizeof(ikm)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_INFO, info, sizeof(info)); status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm) ); The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b 2e 19 18 77 ae, which didn't match the OKM of above test vector. Have we misused the HKDF-EXPAND operation? Best Regards, Poppy Wu 吴偏偏 http://www.mxic.com.cn

2 years, 12 months

2
2
0 0

Please help check the failure of PSA_ALG_HKDF_EXPAND operation test

by Wenhua You

Hi experts, Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on stm32l562e_dk platform. But the HKDF-EXPAND output didn't match the expected OKM. The test vector is as below: ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256), "info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"), "L" : 42, "PRK" : "077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5" "OKM" : "3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865" The corresponding code is as follow： int8_t okm[42]={0}; uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9}; uint8_t ikm[]= { 0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf, 0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63, 0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31, 0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5 }; status = psa_key_derivation_setup(&operation, PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_SECRET, ikm, sizeof(ikm)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_INFO, info, sizeof(info)); status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm) ); The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b 2e 19 18 77 ae, which didn't match the OKM of above test vector. If we've misused the HKDF-EXPAND operation? Best Regards, 尤文华 Wenhua You 旺宏微电子（苏州）有限公司 Macronix Microelectronics(Suzhou) Co., Ltd. 地址：中国苏州工业园区苏虹西路55号 No.55，Su Hong Xi Road，Suzhou Industrail Park，Suzhou 215021 P.R.China TEL: 86-512-62580888 EXT: 3115 FAX: 86-512-62585399 ZIP: 215021 E-mail: wenhuayou(a)mxic.com.cn Http: //www.mxic.com.cn

2 years, 12 months

1
0
0 0

Sealing key - RSS

by Peter Sawicki

As far as ARM CCA is concerned, currently RSS supports only measured boot and delegated attestation (fetching DAK and CCA platform attestation token) interfaces. The Arm CCA Security Model 1.0 mentions that if a Realm wants to implement a persistent secure storage, the platform should deliver binding keys for local protection of persistent Realm assets. Is there any ARM CCA specification that explains how this key should be derived? Are there any plans to implement such functionality in RSS? Kind regards, Peter

2 years, 12 months

3
4
0 0

TF-M scheduling

by Chris.Brand＠infineon.com

Hi, I've read https://tf-m-user-guide.trustedfirmware.org/integration_guide/non-secure_cl… and https://tf-m-user-guide.trustedfirmware.org/design_docs/software/tfm_cooper… but I'm not sure that I understand the whole system. For example, in this scenario: 1. NSPE is running a low-priority thread which has called into the PSA API. S partition is running to do the work. 2. NS interrupt occurs. 3. NS RTOS determines that a higher-priority thread should now run. At step 2, the S context gets stored on the S stack. I guess at step 3 the NS RTOS ISR would manipulate the stack so that it "returns" to the higher-priority NS thread rather than to the secure partition? And then sometime later when it schedules in the low-priority thread, it will return to the interrupted S partition. So the higher-priority thread can also make a PSA API call (provided the NS RTOS is notifying TF-M of the scheduling decisions it makes)? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com/> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

3 years

1
0
0 0

Scheduler problem

by Bohdan.Hunko＠infineon.com

Hi everyone, Why investigation some interrupts related stuff I have noticed a problem/bug in the scheduler. PendSV_Handler has following code: " movs r0, #"M2S(EXC_RETURN_SECURE_STACK)" \n" " mov r1, lr \n" " tst r0, r1 \n" /* NS interrupted */ " beq v8b_pendsv_exit \n" /* No schedule */ Which means that if NSPE was interrupted then no scheduling will be done. This created a problem in following scenario: 1. NSPE is executing 2. Secure interrupts arrives. 3. NSPE is interrupted, secure interrupt is handled. 4. Secure interrupts triggers scheduling of some partition. 5. Secure interrupt returns 6. Scheduling is triggered 7. PendSV returns (because /* NS interrupted */ /* No schedule */ ) and does not perform scheduling even thought pending partition is present. This means that pending partition will only be scheduled when next PSA call will be done be NSPE. Even if there would be subsequent Secure interrupts that preempt NSPE, partition will not be scheduled because PendSV will always return without scheduling because NSPE was interrupted. I was not able to find any information about this in TFM docs so I assume this is a bug. Please let me know if I am wrong. And if this is real problem then is there a plan to fix this? 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>

3 years

2
1
0 0

Support mbedTLS 3.3.0

by S Krishnan, Archanaa

Hi, TF-M v1.7 utilizes mbedTLS v3.2.1. Are there plans to update to mbedTLS v3.3.0? Regards, Archanaa

3 years

2
1
0 0

Partitions without manifest files are not linked correctly in L3

by Bohdan.Hunko＠infineon.com

In isolation level 3 partitions code/data in linker script are gathered together and aligned using information from manifest files. Currently there are 2 partitions that are not using manifest files, and instead have hand written load_info.c files. These partitions are: NS agent trust zone and idle partition. When partition does not have manifest file then its code/data is not gathered together (as there is no manifest to provide needed information). This results in partition code/data being linked directly to SPM. Also code/data may be not correctly aligned (if platform requires special alignment for PSA/APP RoT partitions). For example if platform define custom TFM_LINKER_PSA_ROT_LINKER_DATA_ALIGNMENT, NS agent TZ and idle partitions stacks will not be aligned properly. This is a problem because resulting alignment is not sufficient for the platform, which means that functions that apply protections fail. I see several solutions to this problem: 1. Add alignment to stack of these special partitions. Both the start and the size of the stack should be aligned to satisfy alignment requirements. This is fairly easy fix with small amount of changes. The problem is that code/data of these partitions will still be located in SPM code/data sections which is not ideal solution. I would say this is bare minimum solution, just to make things work. 2. Better solution might be to move these special partitions to now use manifest files. The problem I see is that these partition use special priorities values which are not supported by manifest tool. Also NS Agent TZ uses special PID = 0, which I believe is also not supported by manifest tool. I think this is more time consuming fix but overall this should result in better and easier to understand code. Would be glad to hear a feedback on this topic. 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>

3 years

2
3
0 0

tfm_hal_memory_symbols

by Chris.Brand＠infineon.com

Hi, I'm looking at https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=df87… which added tfm_hal_memory_symbols.{c|h}, containing tfm_hal_sp_meta_start and tfm_hal_sp_meta_end. The former is used in backend_ipc.c, while the latter is unused. The commit message says "this is the first example of using defined symbols to get memory info" but that commit is over two years old now and there doesn't seem to be a second example. Is there still a plan to move in this direction? If so, can somebody outline what that involves? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

3 years

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M