- TF-M - lists.trustedfirmware.org

[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

17 hours, 16 minutes

2
1
0 0

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

3 days, 17 hours

2
1
0 0

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

5 days, 20 hours

1
0
0 0

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

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

1 week, 5 days

1
0
0 0

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

2
1
0 0

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

2 weeks, 4 days

15
113
0 0

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

2 weeks, 5 days

1
2
0 0

Re: no ATU setting in RDV3r1 with TF-M v2.3.0

by 김륜현

Hi Nick First, i share that i'm reviewing TF-M v2.3.0 with tag https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-fi… In the shared commit, platform/ext/target/arm/rse/neoverse_rd/rdv3/bl2/boot_hal_bl2.c call atu_rse_drv_init() in boot_platform_post_init() like below. int32_t boot_platform_post_init(void) {     int32_t result;     enum atu_error_t atu_err;     result = rse_sam_init(RSE_SAM_INIT_SETUP_FULL);     if (result != 0) {         return result;     }     atu_err = atu_rse_drv_init(&ATU_DEV_S, ATU_DOMAIN_ROOT, atu_regions_static, atu_stat_count);     if (atu_err != ATU_ERR_NONE) {             return result;     } But, atu_rse_drv_init don't be called in platform/ext/target/arm/rse/neoverse_rd/rdv3r1/bl2/boot_hal_bl2.c anywhere. So, i tried to find ATU setting to other sources in RDV3R1 platform, i couldn't find ATU setting to load post image. Is there any codes setting ATU for each processor region that image will be loaded? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Nicola Mazzucato <Nicola.Mazzucato(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr> 날짜: 2026-05-13 17:01:37 제목: Re: [TF-M] no ATU setting in RDV3r1 with TF-M v2.3.0 Thanks RH Kim, The commit you shared did not remove any ATU initialisations from what I see. To understand better, are you working on a branch or old commit where you see atu_rse_drv_init for RDV3R1? If so, can you please share? I'm also not very familiar with that platform so it's likely I'm missing something, though it seems that the platform_post_init sequence is different from RDV3. Thanks Best regards, Nick From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 May 2026 03:16 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] no ATU setting in RDV3r1 with TF-M v2.3.0   Dear all, i'm developing the RSE firmware based on rdv3r1. I'm reviewing TF-M v2.3.0 was recently released for checking difference our project codes. Among many differences, i discovered missing ATU settings to load post processor images. In the similar platform rdv3, it calls atu_rse_drv_init() at boot_platform_post_init().  But rdv3r1 doesn't call atu_rse_drv_init() also i can't found ATU settings to load post images in BL2. Is there any intentions? Or was it just missing while integrating by this commit https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/… Please check it  Best Regards RH Kim

1 month, 1 week

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M