- TF-M - lists.trustedfirmware.org

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 days, 8 hours

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 days, 21 hours

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 days, 21 hours

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

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

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

3 months, 3 weeks

1
1
0 0

Inquiry for crypto opaque functions

by 김륜현

HI, i'm developing the RSE firmware based on TF-Mv2.3.0(with TF-Mv2.3.0 release tag) for the our platform that refers to rdv3r1. In TF-M runtime security service, it needs a IAK(Initial Attestation Key) derived by IAK seed to create IAT(Initial Attestation Token). When i checked tfm_plat_get_iak(), it gets IAK_seed by just reading KMU slot which IAK_seed is stored. However, the KMU keyslot storing IAK_seed have been locked since IAK_seed is created so that IAT creation is failed. I was checking possible ways that exports locked key in KMU keyslot and found some evidence in the source codes. That is using CC3xx opaque key that is the method using the KMU export with keyslot index instead using raw key values. Currently, it seems that cc3xx opaque keys feature is supported only for HW keys and AES / CMAC algorithm. However, IAK_seed is stored in S/W keyslot and IAK needs ECC algorithm derivation. (CC3xx lowlevel seems to support it but PSA crypto driver doesn't support it) According to TODO comments like below, it seems that there is some long term plan about it. (I guess that it will be removed When PSA crypto driver supporting all keys and algorithm is implemented) rse_setup_iak_seed()(a)rse_kmu_keys.c /* TODO: Should be removed once setup_key properly locks KMU slots */kmu_err = kmu_set_key_locked(&KMU_DEV_S, RSE_KMU_SLOT_IAK_SEED);if (kmu_err != KMU_ERROR_NONE) {    return (enumtfm_plat_err_t) kmu_err;} Are there any plans or progress regarding this? Best Regards RH Kim

3 months, 3 weeks

1
0
0 0

[BUG] Windows build broken: Architectural conflict between CMake object hashing (commit 8df5c30) and hardcoded .o paths

by Sławomir Piotrowski

Hi TF-M Maintainers, I've encountered a systemic build issue when compiling TF-M on Windows using new CMake version (4.2.1+). The build currently fails on Windows, whereas it compiles perfectly fine on Linux (or via Docker or using older CMake vsrsion). After investigating, the root cause appears to be an architectural conflict introduced by commit 8df5c30845fba7e63253c64407d009b40a37ff95. This commit attempts to solve Windows MAX_PATH limitations by forcing CMake to use short object names (hashing and flattening the output paths for .o files). However, multiple parts of the TF-M build system fundamentally rely on predictable, unhashed intermediate object file names. The conflict manifests in at least two critical areas: 1. Image Signing / Bootloader: The build process requires .o files (like signing layouts) to be in specific, predictable locations for the signing process. With path hashing enabled on Windows, the build scripts cannot locate these artifacts. 2. Linker Script(s): At least STM target relies on filename wildcards to place symbols into specific memory sections. In file bl2.ld the script explicitly looks for *mpu_armv8m_drv.o. Since CMake renames this file to a hash on Windows, the rule is silently ignored, causing memory layout failures. The Problem: We cannot simultaneously use CMake object path hashing and rely on predictable intermediate file paths. Relying on .o names in linker scripts is inherently fragile. Proposal: Given that this issue breaks the core Windows build and likely hides more bugs in other target-specific linker scripts or CMake configurations, I suggest reverting commit 8df5c30845fba7e63253c64407d009b40a37ff95 for now. Before re-enabling short object names on Windows, a deeper architectural audit is needed. For example, moving away from file-based section placement in linker scripts and instead using compiler attributes (e.g., __attribute__((section("...")))) directly in the C source code, making the build agnostic to object file names. As I am consuming TF-M primarily through the Zephyr ecosystem, I am not intimately familiar enough with pure TF-M's complex CMake structure to patch all these instances safely myself. Could someone with deeper knowledge of the TF-M build system look into this and decide on the best path forward? Best regards, Sławomir Piotrowski

4 months

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M