- TF-M - lists.trustedfirmware.org

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/>

2 days, 8 hours

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

4 days, 17 hours

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

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

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

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

1
2
0 0

Upcoming TF-M v2.3.1 and v2.1.6 Releases

by Anton Komlev

Hello, Following the recent releases of the PSA Crypto and Mbed TLS libraries we're preparing two new TF-M maintenance releases: v2.3.1 and v2.1.6. These releases will include the latest security fixes from PSA Crypto and Mbed TLS, along with a few minor TF-M fixes. The current tentative plan is to start the release process on August 3 and publish both releases on August 11. If there are any changes you would like to include, please ensure they are reviewed and merged into the corresponding release branches by August 1. For both releases we do not expect platform-specific testing as the changes are platform-independent and CI should provide sufficient validation. However, please feel free to reach out if you have any concerns or anticipate any platform-specific impact. Best regards, Anton

3 months, 2 weeks

2
2
0 0

Local library patching issue

by Bohdan.Hunko＠infineon.com

Hi, I was trying to build TF-M with local libraries and noticed that patches were not applied in that flow. I found an issue with fetch_remote_library() when using local library paths instead of downloading the dependency. The function exposes LIB_FORCE_PATCH, and the documentation says it should control patching when the library source is provided as a local folder. However, in the current implementation this does not really work for local libraries. We have our Modus Toolbox IDE which builds TFM as part of a project where all the libraries are already cloned, thus we need a way to forca patch local sources. Is upstream community interested in this ? If so I can propose a fix soon. A patch is available for review. Best regards, Bohdan Hunko Cypress Semiconductor Ukraine LLC Senior Engineer CSS ICW SW INT BFS SFW Mobile: +380995019714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

4 months, 1 week

1
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M