- TF-M - lists.trustedfirmware.org

Proposal to Change TF-M Technical Forum Cadence

by Anton Komlev

Hello, I'd like to propose changing the TF-M Technical Forum cadence from monthly to quarterly. As TF-M has matured, there are fewer new features and changes that require regular discussion with the wider community. We previously adjusted the forum from bi-weekly to monthly, and more recently many sessions have either had no proposed topics or limited attendance. Moving to a quarterly schedule would better reflect the current level of activity while still providing a regular opportunity for community discussion. We can, of course, arrange ad hoc sessions whenever there is a topic that would benefit from discussion. Please share your thoughts or any concerns about this proposal. If there are no objections by the end of November, we'll go ahead and move the regular forum to a quarterly schedule. Thank you, and best regards, Anton

5 days, 3 hours

1
0
0 0

Unable to determine default CMAKE_INSTALL_LIBDIR directory

by Quach, Brian

Hi, I'm seeing this warning when running cmake from a conan pkg: `/home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/bin/cmake -S . -B build -DTFM_PLATFORM=arm/mps2/an521`. Does anyone know how to fix it? I see the language is set by `project("Trusted Firmware M" VERSION ${TFM_VERSION} LANGUAGES C CXX ASM)`. Per-partition files done: CMake Warning (dev) at /home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/share/cmake-3.21/Modules/GNUInstallDirs.cmake:236 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs. Call Stack (most recent call first): build/lib/ext/mbedcrypto-src/CMakeLists.txt:42 (include) This warning is for project developers. Use -Wno-dev to suppress it. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

6 days, 20 hours

2
2
0 0

TF-M Platform Support on STM32H5F5J-DK: Upstreaming Plan and Questions

by Ziyauddin Dhukka

Hi TF-M team, Hope you are doing well! We are bringing up TF-M on the STM32H5F5J-DK (STM32H5F5, Cortex-M33, 4 MB flash) using ST's OEMiROT boot chain, and we plan to contribute the platform upstream. Before completing the full port, we'd like to check whether ST or anyone else already has STM32H5F5 support in progress. If so, we're happy to collaborate and align rather than duplicate effort. Current status on hardware: TF-M boots successfully on the H5F5J-DK under ST OEMiROT, with TF-M BL2 disabled and OEMiROT acting as the MCUboot-based root of trust. PSA Crypto and Internal Trusted Storage are functional. A Non-Secure Zephyr application runs successfully and accesses TF-M services through the veneers. During the bring-up, we found two issues in the shared STM32H5 support that appear independent of the H5F5 board port. We'd like to submit these separately first. 1. STM32H5 interrupt vector table In: platform/ext/target/stm/common/stm32h5xx/Device/Source/startup_stm32h5xx_s.c parts of the interrupt vector table are guarded by: #if defined(STM32H573xx) || defined(STM32H563xx) For an STM32H5F5 build, this results in an incomplete/incorrect vector table. We observed: 131 vector entries versus 162 IRQs defined for H5F5. 53 empty slots, including RTC_S, FLASH_S, and RCC_S. A Secure-targeted interrupt hitting one of these vectors jumps to address 0 and HardFaults. Three slots mapped to incorrect handlers. For example, the UART7 vector resolves to COMP1_IRQHandler. Vectors 131-161 are missing entirely. The existing table appears correct for H573/H563 but does not cover H5F5. We regenerated the table against the H5F5 IRQn_Type definition and would like to submit this as a standalone fix. Guidance on the preferred upstream mechanism for selecting device-specific vector tables, for example a device macro versus a per-device startup file, would be appreciated. 2. Entropy with CRYPTO_HW_ACCELERATOR=OFF With the crypto accelerator disabled, the STM platform falls back to MBEDTLS_ENTROPY_NV_SEED. In our configuration, the corresponding ITS seed asset is not provisioned, causing psa_crypto_init() to fail during boot. We worked around this by enabling MBEDTLS_ENTROPY_HARDWARE_ALT through TFM_MBEDCRYPTO_PLATFORM_EXTRA_CONFIG_PATH. This appears to expose a more general issue with the STM32 platform configuration when hardware crypto acceleration is disabled. We could not identify an available entropy fallback for this configuration, so we'd like to address this independently of the H5F5 platform patch. Platform specific questions OEMiROT boot flow: Is an ST OEMiROT-based configuration with TF-M BL2 disabled acceptable for an upstream platform? In this configuration, OEMiROT owns image authentication, installation, and rollback protection. STM32CubeH5 1.7.0 provides OEMiROT as the H5F5 reference flow, so we'd like the upstream platform to support this configuration if possible. H5F5 CMSIS/HAL support: TF-M's bundled STM32H5 CMSIS device support predates the H5F5. For our current port, we use the H5F5 headers/HAL support from the Zephyr-pinned hal_stm32 revision, since mixing the older H573-era sources with H5F5 headers leads to register-definition incompatibilities. For upstream TF-M, would the preferred approach be to update the bundled STM32H5 CMSIS/HAL files, or consume the corresponding hal_stm32 support externally? Crypto acceleration: Would there be any objection to adding H5F5 SAES/PKA/HASH acceleration using the existing H573 accelerator support as the model? We would submit this separately after the base platform support is accepted. If there is no conflicting work already in progress, our proposed patch series is: STM32H5 vector-table fix STM32H5 entropy/NV-seed fix STM32H5F5J-DK platform support STM32H5F5 crypto accelerator support We're happy to adjust the patch split or implementation approach based on maintainer preference. We'll submit the patches through GitHub under BSD-3-Clause with DCO sign-off. Please let us know if you need any additional information. Best Regards, Ziyauddin Dhukka Senior Technical Lead +91 9427545552 Ziyauddin.Dhukka(a)einfochips.com<mailto:Ziyauddin.Dhukka@einfochips.com> [eInfochips | Enriching Lives Through Engineering Excellence]<https://www.einfochips.com/> [cid:29b86944-c203-40c6-b638-331943212c39]<https://www.einfochips.com/awards-and-accolades/>

1 week, 3 days

4
6
0 0

Re: [tf-m_v2.2.2] ROTPK revocation and updates question

by 김종혁

Hi. I hope you are doing well. I haven't received any responses yet. If possible, could you please share any basic guidelines or documentation references? Thanks Best Regards Phillip ----- 원본 메시지 ----- 보낸 사람: 김종혁 <phillip3420(a)adtek.co.kr> 받는 사람: tf-m(a)lists.trustedfirmware.org 날짜: 2026-10-22 10:12:52 제목: [tf-m_v2.2.2] ROTPK revocation and updates question Hello. I'm developing the RSE Firmware based on neoverse rdv3r1 and tf-m version 2.2.2 In TF-M v2.2.2, I found code for ROTPK revocation and updates.  I think this code is intended for scenarios where keys,  such as the private key corresponding to a ROTPK, need to be replaced. It seems that revoking or updating a ROTPK is authorized by verifying a signature generated with the private key corresponding to that ROTPK. If this understanding is correct,  I would expect an additional authorization step to take place before TF-M processes the request. For example, if changing ROTPK “A” can be authorized by a signature generated with its corresponding private key, “A_private,” this seems potentially risky from a security perspective. Am I understanding this correctly, or am I missing something? If an additional authorization step is expected before the ROTPK revocation or update procedure in TF-M, could you provide an example of what that step would involve? Thanks Best Regards Phillip

1 week, 5 days

1
0
0 0

Technical Forum call - July 21

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 21, 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Link to the forum: https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 weeks, 3 days

15
123
0 0

[tf-m_v2.2.2] ROTPK revocation and updates question

by 김종혁

Hello. I'm developing the RSE Firmware based on neoverse rdv3r1 and tf-m version 2.2.2 In TF-M v2.2.2, I found code for ROTPK revocation and updates.  I think this code is intended for scenarios where keys,  such as the private key corresponding to a ROTPK, need to be replaced. It seems that revoking or updating a ROTPK is authorized by verifying a signature generated with the private key corresponding to that ROTPK. If this understanding is correct,  I would expect an additional authorization step to take place before TF-M processes the request. For example, if changing ROTPK “A” can be authorized by a signature generated with its corresponding private key, “A_private,” this seems potentially risky from a security perspective. Am I understanding this correctly, or am I missing something? If an additional authorization step is expected before the ROTPK revocation or update procedure in TF-M, could you provide an example of what that step would involve? Thanks Best Regards Phillip

3 weeks, 3 days

1
0
0 0

[tf-m_v2.2.2] ROTPK revocation and updates

by 김종혁

Hello. I'm developing the RSE Firmware based on neoverse rdv3r1 and tf-m version 2.2.2 In TF-M v2.2.2, I found code for ROTPK revocation and updates.  I think this code is intended for scenarios where keys,  such as the private key corresponding to a ROTPK, need to be replaced. It seems that revoking or updating a ROTPK is authorized by verifying a signature generated with the private key corresponding to that ROTPK. If this understanding is correct,  I would expect an additional authorization step to take place before TF-M processes the request. For example, if changing ROTPK “A” can be authorized by a signature generated with its corresponding private key, “A_private,” this seems potentially risky from a security perspective. Am I understanding this correctly, or am I missing something? If an additional authorization step is expected before the ROTPK revocation or update procedure in TF-M, could you provide an example of what that step would involve? Thanks Best Regards Phillip

3 weeks, 3 days

1
0
0 0

Security Advisory: Three New Security Vulnerabilities

by Anton Komlev

Hello, This email is to notify you of 3 new security vulnerabilities affecting Trusted Firmware-M (TF-M). 1. Pre-auth OOB write in RSE SFCP handshake hijacks BL1 boot-ROM control flow Some RSE configurations place nodes in a trusted subnet whose links are initially untrusted, so the SFCP implementation performs a handshake before normal traffic is protected with the negotiated session key. Advisory: https://trustedfirmware-m.readthedocs.io/en/latest/security/security_adviso… Fix: https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/… 1. Plaintext SFCP packet on RSE returns delegated-attestation private key The platform expects that the RSEs in the system are members of the trusted subnet and therefore use encrypted communications. This is not enforced on the "non-interrupt driven" receive code path for sfcp_receive_msg. Therefore, external RSEs in the system could send unencrypted packets which would be successfully received. Advisory: https://trustedfirmware-m.readthedocs.io/en/latest/security/security_adviso… Fix: https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/… 1. OOB flash write in Corstone-1000 update bricks the secure enclave The Corstone-1000 FWU bootloader backend writes update payload blocks directly to flash through ProgramData(). The write address is calculated from the target image partition base plus the number of image bytes already received. Without validating this calculated range against the flash address space and the selected update partition size, a sequence of FWU writes can extend past the end of the intended partition. Advisory: https://trustedfirmware-m.readthedocs.io/en/latest/security/security_adviso… Fix: https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/… If you have any questions or comments, please let us know. Best regards, Anton on behalf of the TF-M Security Team

1 month, 3 weeks

1
0
0 0

Upgrade TF-M default CMake to v4.3

by Anton Komlev

Hello TF-M Community, I'd like to upgrade the default CMake version in TF-M to 4.3.5. Please let me know if you have any objections or foresee compatibility issues with your development environment or downstream projects. If there are no objections by Sep 21, I'll proceed with the upgrade. Thanks, Anton

1 month, 3 weeks

2
2
0 0

TF-M v2.3.0 release announcement

by Anton Komlev

Hello, We're pleased to announce the release of TF-M v2.3.0. Major highlights: * Adoption of TF-PSA-Crypto 1.1.0 in place of Mbed TLS * Extended support for the Clang/LLVM Arm Toolchain for Embedded (ATfE) * TF-M Tests: RTX OS is now built from source This release also includes numerous fixes and improvements - please see the release notes<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/50322/8/docs…> for full details. Release v2.1.5 will follow shortly. Many thanks to everyone who contributed, reviewed, and supported this milestone. Best regards, The TF-M Team

2 months, 4 weeks

1
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M