- TF-M - lists.trustedfirmware.org

increased interrupt latency when calling the PSA PS API

by Fontanilles, Tomi

Hi all, I'm currently looking into an issue reported internally where the maximum latency for a zero-latency, priority 0 interrupt dramatically increases during a call to the PSA Protected Storage (PS) API. The maximum interrupt latency goes up ~10-fold, or even some more at times (it varies), and this is not acceptable to code running on the NS side for normal operation. It's as simple as calling psa_ps_set(1, 4, buf, PSA_STORAGE_FLAG_NONE) once. During that call (which I am told was also seen to be unreasonably long: 600ms for 4 bytes, 1s for 1000 bytes), the maximum interrupt latency goes up. It (the maximum) seems to not vary too much even if increasing the size of stored assets (tested up to 4000 bytes), though it can get up to 20 times higher than the normal interrupt latency. Also, other functions were tested (psa_generate_random(), psa_hash_compute()). Those don't provoke an increased interrupt latency. Maybe it's only about the PS, or maybe some other calls can provoke that as well. Does someone have an explanation for that? And even more importantly, can that interrupt latency be reduced, ideally down to normal levels? Thanks in advance. Tomi

2 months, 1 week

2
5
0 0

Set PSA_2_0_0 as default attest profile and removal of PSA_IOT_PROFILE_1

by Tamas Ban

Hi, We are going to set the PSA_2_0_0 profile as the default for the initial attestation service. This will impact which claims are included in the token and their key values. More details are here: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-24.html Changes on review: https://review.trustedfirmware.org/q/topic:%22attest_profile_update%22 As a follow-up action, the PSA_IOT_PROFILE_1 is being deprecated. We are planning to remove it from the code base as well. To figure out the timing of this we would like to collect some data: * If you are using the PSA_IOT_PROFILE_1 please let us know what would be a feasible time for you to switch over the PSA_2_0_0 profile. Thanks! Best regards, Tamas Ban

2 months, 2 weeks

3
2
0 0

Discussion on TF-M Copyright notices update

by Anton Komlev

Hello, I would like to open discussion on TF-M copyright notice unification following other projects in TrustedFirware.org<https://www.trustedfirmware.org/> which already adopted Linux Foundation copyrights<https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-…>. With the change TF-M copyright notice will be unified to: Copyright (c) XXXX[-YYYY], The TrustedFirmware-M Contributors. All rights reserved. The change to the contribution process is proposed here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/31664 Please share your thoughts on the subject. I plan to bring this topic to the tech forum agenda on Thursday. Please join the discussion. Thanks, Anton

2 months, 3 weeks

1
1
0 0

PSA Certification for TF-M

by Zhang, Hao

Hi TF-M committee, I have a question regarding PSA certification. Am I understanding correctly that if a platform wants to be ported to TF-M and the product wants to pass PSA certified, the TF-M version needs to come from a certain LTS tag release (e.g. TF-M v2.1.0<https://github.com/TrustedFirmware-M/trusted-firmware-m/tree/TF-Mv2.1.0> with commit 0c4c99b<https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/0c4c99ba33b3…> that was pushed 5 months ago). However, Zephyr v3.7.0 is using TF-M version<https://github.com/zephyrproject-rtos/zephyr/blob/v3.7.0/west.yml#L330C17-L…> that is updated after TF-M v2.1.0. Does that means efforts need to be done to manually modify west.yml in Zephyr to roll back to the tag release of v2.1.0 for PSA certification? Thank you very much, Best, [https://opengraph.githubassets.com/f92ee5eaaedaf25d7ae17b5e8fc073a1573b0f31…]<https://github.com/zephyrproject-rtos/zephyr/blob/v3.7.0/west.yml#L330C17-L…> zephyr/west.yml at v3.7.0 · zephyrproject-rtos/zephyr<https://github.com/zephyrproject-rtos/zephyr/blob/v3.7.0/west.yml#L330C17-L…> Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures. - zephyrproject-rtos/zephyr github.com [https://opengraph.githubassets.com/685e753ecccd8431b5e0c4ed32fb794a49e2bcb3…]<https://github.com/TrustedFirmware-M/trusted-firmware-m/tree/TF-Mv2.1.0> GitHub - TrustedFirmware-M/trusted-firmware-m at TF-Mv2.1.0<https://github.com/TrustedFirmware-M/trusted-firmware-m/tree/TF-Mv2.1.0> Read-only mirror for Trusted Firmware-M. Contribute to TrustedFirmware-M/trusted-firmware-m development by creating an account on GitHub. github.com Best regards, Hao

2 months, 3 weeks

3
6
0 0

Security vulnerability notice - Unchecked user-supplied pointer via mailbox messages may cause write of arbitrary address

by Anton Komlev

Hello, This email is a notification of a new security vulnerability reported to TF-M by Infineon Technologies AG, in collaboration with: Tobias Scharnowski, Simon Wörner and Johannes Willbold from fuzzware.io. Unchecked user-supplied pointer via mailbox messages may cause write of arbitrary address. Please find the security advisory attached. The fix has been merged on the latest main branch tfm_spe_mailbox: Do not write-back on input vectors checks failure<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/31512> We're preparing a hotfix release v2.1.1 to include fixes for this vulnerability and bugs reported till that date via TF-M issue tracker: https://github.com/TrustedFirmware-M/trusted-firmware-m/issues?q=is%3Aissue Thanks and best regards Author

2 months, 4 weeks

1
0
0 0

QEMU usage

by Matthew Dalzell

Hi everyone, It has come to our attention that QEMU is no longer able to run the regression tests in a timely manner, and before we go ahead and outright disable them, we would like to know if anyone is using QEMU for their platform testing. If so, please reply to this message and we can have further discussion on the point. Thanks, Matt

2 months, 4 weeks

2
1
0 0

Re: Looking for suggestions about make Mbed TLS APIs non-secure callable APIs on armv8m

by Shebu Varghese Kuriakose

+ TF-M mailing list From: David Horstmann via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Tuesday, September 24, 2024 5:14 PM To: mbed-tls(a)lists.trustedfirmware.org; Lee, William <William.Lee(a)garmin.com> Subject: [mbed-tls] Re: Looking for suggestions about make Mbed TLS APIs non-secure callable APIs on armv8m Hi William, Since Mbed TLS is a cross-platform library, we don't deal directly with TrustZone-M. However, if I have understood correctly, I think your usecase is solved by the Trusted Firmware M (TF-M) project[1], which is an implementation of secure firmware that provides cryptography services via non-secure-callable APIs. TF-M uses Mbed TLS internally and implements the PSA Certified Cryptography API[2]. The Crypto Service Integration Guide[3] in the documentation should be a good starting point for what you are trying to do. I hope that helps, David Horstmann Mbed TLS developer [1] https://www.trustedfirmware.org/projects/tf-m [2] https://www.psacertified.org/getting-certified/crypto-api-compliance/ [3] https://trustedfirmware-m.readthedocs.io/en/latest/integration_guide/servic… [https://www.trustedfirmware.org/images/social-media-image.png]<https://www.trustedfirmware.org/projects/tf-m> TrustedFirmware-M (TF-M)<https://www.trustedfirmware.org/projects/tf-m> TrustedFirmware-M (TF-M) implements the Secure Processing Environment (SPE) for Armv8-M, Armv8.1-M architectures or dual-core platforms. www.trustedfirmware.org<http://www.trustedfirmware.org> ________________________________ From: Lee, William via mbed-tls <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> Sent: 24 September 2024 15:08 To: mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> Subject: [mbed-tls] Looking for suggestions about make Mbed TLS APIs non-secure callable APIs on armv8m Hi Mbed TLS, I am looking for some suggestions about make some (or all) Mbed TLS APIs non-secure callable APIs on armv8m. The background is that I am going to have a secure firmware that provides encryption services by building part (or whole) of Mbed TLS into that firmware and make those original mbedtls_x APIs non-secure callable, so the existing non-secure firmware could link those non-secure callable APIs and use them. Some of my thoughts: (1) The easiest way to do it I can think of is just add the attribute "cmse_nonsecure_call" to those APIs' declaration (or use a macro to wrap the attribute for conditional build to not impact others don't want it), but I do not think this modification could be accepted by upstream 🙂. (2) So my another thought is duplicate all header files and put them under another folder, assuming it is my-include folder, then I can do whatever I want to my-include folder, but there is also a problem I can think of: a merge/compare burden between include and my-include folder after I have updated Mbed TLS. I really appreciate other suggestions! Thanks, William

3 months

2
1
0 0

Re: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform

by Mark Chen

Hi all, I am working on integrating our IP(PUFcc) into TF-Mv2.1.0, with the PUFcc located at address 0x51700000. The PUFcc can be access on bl2 stage, however, it cannot be access on booting tf-m stage. The exception log as below: [cid:image002.png@01DAEFC7.96FE4EB0]FATAL ERROR: HardFault Here is some context for the exception: EXC_RETURN (LR): 0xFFFFFFF1 Exception came from secure FW in handler mode. xPSR: 0x00000003 MSP: 0x31000B18 PSP: 0x31000BF8 MSP_NS: 0xFFFFFFFC PSP_NS: 0xFFFFFFFC Exception frame at: 0x31000B18 R0: 0x31000B60 R1: 0x00000000 R2: 0x0000001B R3: 0x00000002 R12: 0x00000000 LR: 0x38009EF7 PC: 0x3800AB02 xPSR: 0x6100000B Callee saved register state: R4: 0xFFFFFFF9 R5: 0x31000B60 R6: 0x00000002 R7: 0x00000002 R8: 0x38030F24 R9: 0x0000001B R10: 0x00000011 R11: 0x38030F11 CFSR: 0x00008200 BFSR: 0x00000082 BFAR: 0x00000004 MMFSR: 0x00000000 MMFAR: Not Valid UFSR: 0x00000000 HFSR: 0x40000000 SFSR: 0x00000000 SFAR: Not Valid The diff patch as below: [cid:image003.png@01DAEFC7.96FE4EB0]--- a/secure_fw/spm/core/main.c +++ b/secure_fw/spm/core/main.c @@ -56,6 +56,9 @@ static fih_int tfm_core_init(void) */ SPMLOG_INFMSG("\033[1;34mBooting TF-M "VERSION_FULLSTR"\033[0m\r\n"); + uint32_t* p_s = (uint32_t *)0x51700000; + printf("p_s = %08x\n", (uint32_t)*p_s); Could you provide any suggestions on this issue? Best regards, Mark Chen Research & Development Division II PUFsecurity Corporation Tel: 886-3-5601010 ext. 3110 Fax: 886-3-5601177 Email: mark(a)pufsecurity.com<mailto:mark@pufsecurity.com> [cid:image001.png@01DAEFC5.FD4AE270] From: Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>> Sent: Thursday, August 1, 2024 12:12 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: Randy Liu <randyliu(a)pufsecurity.com<mailto:randyliu@pufsecurity.com>>; Victor Huang <victor(a)pufsecurity.com<mailto:victor@pufsecurity.com>>; Neil Chen <neilchen(a)pufsecurity.com<mailto:neilchen@pufsecurity.com>>; Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com<mailto:Shebu.VargheseKuriakose@arm.com>> Subject: Re: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform Hi Anton, Thank you and enjoy your time!!! Best, Andy ________________________________ 寄件者: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> 寄件日期: Wednesday, July 31, 2024 11:34:48 PM 收件者: Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>> 副本: Randy Liu <randyliu(a)pufsecurity.com<mailto:randyliu@pufsecurity.com>>; Victor Huang <victor(a)pufsecurity.com<mailto:victor@pufsecurity.com>>; Neil Chen <neilchen(a)pufsecurity.com<mailto:neilchen@pufsecurity.com>>; Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com<mailto:Shebu.VargheseKuriakose@arm.com>> 主旨: RE: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform HI Andy, Great to hear good news. I will be in annual leave from tomorrow, Aug 1st, but Antonio (coped) could help you and can redirect the possible questions to appropriate team members. With the occasion, I would appreciate if your team evaluates and follows TF-M documentation and gives us feedback on possible confusion or missing information. Best regards, Anton From: Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>> Sent: Wednesday, July 31, 2024 3:26 PM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: Randy Liu <randyliu(a)pufsecurity.com<mailto:randyliu@pufsecurity.com>>; Victor Huang <victor(a)pufsecurity.com<mailto:victor@pufsecurity.com>>; Neil Chen <neilchen(a)pufsecurity.com<mailto:neilchen@pufsecurity.com>> Subject: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform #Set a new mail loop Hi Anton, We set a kick-off meeting of "PSA Crypto API with PUFcc on the TF-M platform" this week. • TF-M v2.1.0 • PSA Crypto API - v1.2.1 • PSA Certified APIs Architecture Test Suite - v1.6 • MPS3 with AN552 Randy, Victor, and Neil are members of this project. We would have many issues when developing that need your help to solve it. Please feel free to add your teams. Let's make the project successful. Thank you very much. Have a Nice Day, Andy [cid:image001.png@01DAEFC5.FD4AE270] 熵碼科技股份有限公司 Tel: 886-3-5601010 #2119 Email: andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com> Website: https://www.pufsecurity.com/ -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------

4 months, 2 weeks

3
2
0 0

ARMCLANG generates ELF with armv3m architecture

by Roman.Mazurak＠infineon.com

Hello, We noticed that build of TF-M for CM33 platform generates ELF file for which architecture is armv3m. Step to reproduce: 1. Build TF-M secure image for CM33 platform with armclang (used 6.19). 2. Use arm-none-eabi-objdump provided with arm-gnu-toolchain-11.3.rel1-mingw-w64-i686-arm-none-eabi to print headers: * arm-none-eabi-objdump -x tfm_s.axf You will see following output: tfm_s.axf architecture: armv3m, flags 0x00000012: EXEC_P, HAS_SYMS While fromelf (from armclang) prints following: ======================================================================== ** ELF Header Information File Name: tfm_s.axf Machine class: ELFCLASS32 (32-bit) Data encoding: ELFDATA2LSB (Little endian) Header version: EV_CURRENT (Current version) Operating System ABI: none ABI Version: 0 File Type: ET_EXEC (Executable) (2) Machine: EM_ARM (ARM) Image Entry point: 0x16004319 Flags: EF_ARM_HASENTRY + EF_ARM_ABI_FLOAT_HARD (0x05000402) ARM ELF revision: 5 (ABI version 2) Is't expected? Because we have problems with debugging images generated by armclang in eclipse with gdb. Regards, Roman.

4 months, 2 weeks

2
1
0 0

Improved linker files supporting TF-M isolation L1-3

by Jamie Fox

Hi all, I have pushed for review a change to improve the TF-M linker scripts / scatter files: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/30316 There are two ideas behind the change: * Merge the isolation level 3 features from the tfm_isolation_l3 linker files into tfm_common_s, so that one linker file can support all TF-M isolation levels. * Group the memory by its desired memory protection attribute as far as possible, so that as much of the memory map as possible can be covered by MPU regions to restrict the attributes to no more than needed. The main advantage of this is to reduce how much of the memory is executable. There are more details in the commit message. Since it could be a disruptive change, the new linker files are added in addition to the existing tfm_common_s.sct/ld/icf and tfm_isolation_l3.sct/ld/icf ones and only platforms that are already using the common tfm_hal_isolation_v8m.c are switched over for now. But the idea is that platforms can gradually migrate and eventually the existing linker files can be removed. Kind regards, Jamie

4 months, 2 weeks

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M