TF-M June 2026

tf-m@lists.trustedfirmware.org

8 participants
9 discussions

[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

3 days

Stm32: Memory mapped external Flash not available for non secure domain

by Sławomir Piotrowski

Hello, I'm working with the STM32U585 on the b_u585i_iot02a board using Zephyr and TF-M. Currently, the OSPI2 controller itself is correctly assigned to the Non-Secure (NS) domain, allowing standard indirect flash operations. However, when I enable the Memory-Mapped mode for the external flash, any read attempt (e.g., using memcpy via flash_read) immediately triggers a SecureFault. This happens because the memory-mapped region (0x70000000) is not configured as Non-Secure in the SAU and GTZC (MPCWM) during the TF-M boot process. Since the configuration file (platform/ext/target/stm/common/stm32u5xx/secure/target_cfg.c) is located in the common directory rather than the board-specific folder, it's difficult to override this behavior cleanly in an out-of-tree custom board definition. Proposed Solution: I suggest adding a conditional configuration in target_cfg.c that checks for board-specific definitions (e.g., EXTERNAL_FLASH) to explicitly allow NS/Unprivileged read access to the OSPI mapped region. I have attached a patch demonstrating this simple fix. Note: Since the OSPI peripheral is already exposed to the NS domain, granting access to its memory-mapped region does not introduce a new security risk (an attacker could already read the flash via indirect commands). It simply restores the intended functionality. Alternatively, an architectural redesign - such as moving board-specific security configs out of common or providing __weak hooks for board files - would be ideal, but this simple patch resolves the immediate blocker. thank you, Sławomir Piotrowski

6 days

STM32U5: BL2 HardFault after HDP activation due to missing .BL2_NoHdp_Code in MPU driver

by Sławomir Piotrowski

Description: When booting TF-M 2.3.0 on the STM32U5 platform with TFM_HDP_PROTECT_ENABLE=1, a Secure HardFault occurs in BL2 right before jumping to the primary image. The fault is caused by an instruction fetch error from the hidden memory area because the MPU configuration functions lack the necessary section attributes. Execution Flow & Root Cause: boot_platform_start_next_image() is called. It invokes LL_SECU_UpdateRunTimeProtections(), which enables the hardware Hide Protection (HDP) firewall. From this point, most of the BL2 flash area becomes unreadable/unexecutable. It then calls mpu_appli_cfg(). This function is correctly placed outside the firewall using __attribute__((section(".BL2_NoHdp_Code"))). However, mpu_appli_cfg() calls mpu_armv8m_region_enable() (located in mpu_armv8m_drv.c). BUG: mpu_armv8m_region_enable() does not have the .BL2_NoHdp_Code attribute. Since it resides in the standard .text section hidden by HDP, the CPU immediately throws a HardFault when trying to execute it. Stack Trace: mpu_appli_cfg @ 0x0c036182 LL_SECU_UpdateRunTimeProtections @ 0x0c03614e boot_platform_start_next_image @ 0x0c036078 do_boot @ 0x0c014e38 main @ 0x0c01505e Proposed solution: Add __attribute__((section(".BL2_NoHdp_Code")) guarded by #ifdef BL2 to mpu_armv8m_region_enable() and mpu_armv8m_region_enable_check(). thank you, Sławomir Piotrowski

1 week, 1 day

Re: Proposal to unify tf.org vulnerability referencing in NVD

by sandrine.afsa＠arm.com

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

1 week, 3 days

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>

2 weeks

BL2 support for STM32U3 platform

by Jaun, Mario

Hello We are interested in integrating TF-M into a project which is based on a STM32U3 MCU. The documentation states under limitations "TF-M Supported without BL1/BL2". Are there technical reasons that BL2 is not supported? If no, is support planned to be implemented in the near future? If no, would you be open for contributions regarding adding BL2 support? Thanks for your response. Best Mario

2 weeks, 5 days

Proposal to unify tf.org vulnerability referencing in NVD

by sandrine.afsa＠arm.com

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

2 weeks, 6 days

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, 6 days

CI infrastructure scheduled maintenance: 4th June Sep 2026

by Saheer Babu

Hi all, We will be upgrading Cloudbees CI and clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Wednesday, 3rd June 2025 at 16:00 GMT+1. During this maintenance window, both services will be unavailable for approximately 8 hours. A follow-up email will be sent once the services are fully restored. Best regards, Saheer [LOGO SMALL] Saheer Babu Principal Software Engineer CESW – Engineering Infrastructure

3 weeks

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M June 2026