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

15
116
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 weeks, 4 days

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>

1 month, 2 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

1 month, 2 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

1 month, 3 weeks

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

1 month, 4 weeks

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

2 months

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.

2 months

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 months, 1 week

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 months, 1 week

1
0
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 months, 2 weeks

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

3 months

1
0
0 0

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

by 김륜현

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

3 months

2
1
0 0

TF-M v2.1.5 release announcement

by Anton Komlev

Hello, I am pleased to announce the release of TF-M v2.1.5. Major highlights: * SPM: Fixes for FPU context cleanup, add r12 into caller context clearing * Upgrade to MbedTLS v3.6.6, which contains security advisories. Please see the release notes<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/50758/2/docs…> for full details. Many thanks to Nicola Mazzucato for leading this step, and to everyone who supported this milestone. Best regards, Anton

3 months, 1 week

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

3 months, 1 week

1
1
0 0

Need STM32 crypto accelerator support in v2.3.0

by Michael Grand

Dear all, I have seen that hw crypto acceleration has been removed from Stm32 platform in v2.3.0. I was eagerly waiting for this new LTS version however lack of crypto acceleration support for stm32 is a no go for me. Is there a plan to add crypto acceleration support later ? Or maybe I have missed something ? Best regards, Michael Grand

3 months, 2 weeks

1
0
0 0

TF-M 2.3 PSA arch tests build fails for CM55 core

by Bohdan.Hunko＠infineon.com

Hi all, Currently build of psa arch tests fail for CM55 core of our PSE84 platform File: api-tests/tools/cmake/compiler/{ARMCLANG,GNUARM}.cmake (same in secure-debug/). Problem: The toolchain file unconditionally adds -march=... derived from CPU_ARCH. When built inside TF-M, mcpu_features.cmake already sets -mcpu=... with extension toggles. The compiler then sees two CPU specs that disagree on extensions. Why CM33 works, CM55 doesn't: CM33: -mcpu=cortex-m33 and -march=armv8-m.main describe the same extension set → accepted. CM55: -mcpu=cortex-m55+nomve+... and -march=armv8.1-m.main disagree on MVE/FP → rejected. Fix (generic): Skip the -march block when an outer build already selects the CPU (e.g. TFM_SYSTEM_PROCESSOR defined, or CMAKE_C_FLAGS contains -mcpu=/--target=). Long-term: switch psa-arch-tests to -mcpu-based selection. We have not yet pushed PSE84 psa arch tests target, but maybe this can be check by ARM team using one of ARM CM55 based platforms (e.g. Corstone-300 (MPS3))? 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

2
2
0 0

Upcoming TF-M Releases: v2.3.0 and v2.1.5

by Anton Komlev

Hello, We're preparing two new TF-M releases: v2.3.0 and v2.1.5. The current plan is to start on April 1st and target April 14th for v2.3.0. Among other improvements and fixes, v2.3.0 will be based on PSA-Crypto v1.1 expected on March 31st . We'll aim to test both releases in parallel with priority given to v2.3.0, while v2.1.5 will follow. If there are any changes you'd like included in these releases, please ensure they are reviewed and merged by March 31st. After successful testing of the v2.3.0 on platforms in OpenCI we plan to allow a one-week window for other platforms to validate and confirm correct operation. For v2.1.5, we don't expect platform-specific testing, assuming the changes are platform-independent and that CI coverage will be sufficient. However, please feel free to reach out if you have any concerns or anticipate any platform impact. Thank you and best regards, Anton

3 months, 3 weeks

1
3
0 0

[TF-M 2.2.2] Inquiry Regarding vHUK Seed Array Inconsistency Among Clients During rse_handshake in Multi-RSE Topology

by 박진국

Hello, I am currently developing with the Multi-RSE Topology and have an inquiry regarding the following *1. Overview & Environment* - *Version:* Trusted Firmware-M (TF-M) 2.2.2 - *Target Architecture:* MULTI_RSE_TOPOLOGY enabled environment - *Related Modules:* boot_hal_bl1_2.c, rse_handshake.c *2. Background & Code Analysis* We are currently analyzing the BL1 boot sequence code to set up a Multi-RSE environment. Looking at the boot_platform_post_init() function in platform/ext/target/arm/rse/common/bl1/boot_hal_bl1_2.c, the vHUK is generated in the following sequence: 1. Calls rse_derive_vhuk_seed() 2. Checks the CM_POLICIES_VHUK_AGREEMENT_REQUIRED policy, then executes rse_handshake(vhuk_seed) 3. Calls rse_setup_vhuk() to derive the final vHUK based on the aggregated Seed array. *3. Issue Description* However, upon analyzing the operational structure in rse_handshake.c, we suspect a synchronization defect exists where the Server (Primary RSE) and multiple Clients (Secondary RSEs) will end up generating different final vHUKs. - Looking at the rse_handshake_server() logic, the server replies to the client *immediately* within the receive loop with the *currently* aggregated vhuk_seeds_buf every time it receives a Seed from a client. - Because of this behavior, Client 1 (the first to connect) receives an incomplete array (e.g., [C0, C1, 0, 0]) that lacks the seeds of subsequent clients. Only the last client to connect receives the fully populated array ([C0, C1, C2, C3]). - Consequently, each Client executes rse_setup_vhuk() with a different state of vhuk_seeds_buf. This ultimately leads to mismatched final vHUK values across the RSEs within the system. *4. Questions* 1. Is this behavior (returning an incomplete Seed array based on the client connection order) an intended operation within the security architecture? 2. If this is not intended, is this a known bug in TF-M 2.2.2 where the logic for the Server to broadcast (or perform a 2-Phase synchronization of) the completed array to all clients *after* gathering all seeds is missing? 3. Could you please provide a workaround for this issue, or guide us to a specific patch/commit if this has been resolved in a newer version? Thank you in advance for your support.

3 months, 4 weeks

1
0
0 0

[PATCH 00/20] platform: stm: STM32H563 TF-M support

by Steven Friedman

On 17 March 2026 Mogens Lund (mogens.lund(a)prevas.dk) asked on this list whether STM32H563 TF-M support was planned, and whether there was a defined path for upstreaming a clone-and-adapt of the existing STM32H573I-DK port. This patchset provides that support: it extends the shared platform/ext/target/stm/common/stm32h5xx/ code to cover STM32H563 alongside STM32H573 and adds a NUCLEO-H563ZI board port that builds and runs on real hardware today. Twenty patches, internally organised into three groups that review independently: Group A [01..13] Generic STM32H5xx improvements. Every patch in this group changes STM32H573 runtime behaviour (correctness fixes, defensive hardenings, chip-family additions applicable to both H563 and H573). No #ifdef guards. Group B [14..19] STM32H563 chip-variant support. Four commits (14-17) are mechanical enablers -- linkage changes and defensive conditionals that are no-ops on H573 but required by group C. Two commits (18-19) are H563-only behaviour under #ifdef STM32H563xx; H573 is unaffected. Group C [20] NUCLEO-H563ZI board port at platform/ext/target/stm/nucleo_h563zi/, structurally mirroring the existing platform/ext/target/stm/stm32h573i_dk/ port. Thirteen of nineteen files are verbatim copies from stm32h573i_dk with original headers preserved; five contain authored content (CMakeLists.txt, cpuarch.cmake, include/board.h, include/stm32hal.h, secure/low_level_device.c); one (cpuarch.cmake) is adapted from stm32h573i_dk with a one-word chip-identifier change. See the commit body for the full file-by-file provenance. Group A patches --------------- 01 fix dual-bank flash page addressing 02 wait for HSI48 ready before RNG init 03 map fault vectors to proper handlers 04 improve Error_Handler debug spin 05 extend system-memory SAU region to cover UID (H573 also gains NS UID access; RM0481 section "Unique device ID register") 06 add SAU region for OCTOSPI1 XIP aperture 07 enable SRAMx clocks before MPCBB programming (RM0481 section "RCC_AHB2ENR" -- SRAM2EN / SRAM3EN default to 0 on reset) 08 allow NS access to I/DCACHE register interfaces 09 guard SysTick init in UART stdio driver 10 default CONFIG_TFM_ENABLE_CP10CP11 ON for stm32h573i_dk (matches platform/ext/target/adi/max32657/cpuarch.cmake precedent; docs/integration_guide/tfm_fpu_support.rst section "FPU support") 11 enable configurable fault handlers in boundary setup 12 lock Secure MPU configuration after setup 13 refresh SystemCoreClock before RNG_Init Group B patches --------------- 14 expose mpu_init() for platform overrides (linkage only -- drops 'static'; no runtime change) 15 drop static from n_configured_regions (same rationale as 14) 16 skip scratch flash area when it is not defined (conditional on FLASH_AREA_SCRATCH_OFFSET; H573's flash_layout defines it so H573 behaviour is unchanged) 17 clear AIRCR.BFHFNMINS defensively in boundary setup (no-op on H573 because Reset_Handler's LOCKSVTAIRCR lock stuck; documented mechanism for parts where it did not) 18 skip LOCKSVTAIRCR check for H563 (#ifdef STM32H563xx -- parts with BOOTHDPL = 0x01 boot at HDPL1 so the lock write is silently ignored; self-retiring when production parts ship with BOOTHDPL = 0x00) 19 skip PKA / AES / SAES TZSC config on H563 (#ifdef STM32H563xx -- H563 has none of those peripherals) Group C patch ------------- 20 add NUCLEO-H563ZI board port Dependency on STMicroelectronics' cmsis-device-h5 ------------------------------------------------- Group C compiles cleanly against the TF-M tree only after the STM32H563 CMSIS device header has been imported. The canonical source is https://github.com/STMicroelectronics/cmsis-device-h5 at the latest stable tag (v1.5.0 at the time of writing). The required imports are: 1. Add platform/ext/target/stm/common/stm32h5xx/Device/Include/stm32h563xx.h copied verbatim from the cmsis-device-h5 repository above. 2. Extend platform/ext/target/stm/common/stm32h5xx/Device/Include/stm32h5xx.h with an #elif defined(STM32H563xx) branch that #includes "stm32h563xx.h", mirroring the existing #if defined(STM32H573xx) branch. Neither change is included in this patchset because groups A and B touch zero H563-specific register symbols -- every patch tests only the STM32H563xx build macro. I would appreciate guidance from ST on whether they would like to handle the vendor import themselves (same mechanism as the existing stm32h573xx.h), or whether they would prefer a follow-up patch from me that does the import. Testing ------- All 20 patches applied together and boot-tested on NUCLEO-H563ZI hardware with a Zephyr 4.4 NSPE (CONFIG_FPU=y, thumbv8m.main-none-eabihf): BL2 -> TF-M SPE at isolation level 2 -> Zephyr NSPE hands off cleanly, zero SecureFault / HardFault / MemManage / BusFault. NS FPU access works across the S/NS boundary via the SPM-level CP10/CP11 programming enabled by the nucleo_h563zi cpuarch.cmake. I do not have an STM32H573I-DK board. Group A is expected to be strictly behaviour-improving on H573 (correctness fixes, defensive hardenings, plus patch 10 which enables a cmake knob that the stm32h573i_dk port today leaves off), but confirmation from ST or other H573 users during review would be welcome. -- STEVEN FRIEDMAN SENIOR STAFF ENGINEER *P:* 301.298.7997x168 *E:* friedman(a)ionq.co *W: *www.ionq.co

3 months, 4 weeks

2
1
0 0

TF-M to stm32h563

by Mogens Lund

Hi Is there any plans to include the STM32H563 as a supported TF-M platform ? If I clone the existing STM32H573_DK and adapts it to the STM32H563, what is then the process to get it upstreamed ? Med venlig hilsen / Best regards Mogens Lund SW Designer [e-logga-signatur-2] Niels Jernes vej 14, 9220 Aalborg Ø, Denmark Mobile: +45 2677 8879 Switchboard: +45 3315 9090 mogens.lund(a)prevas.dk<mailto:henrik.moller@prevas.dk> www.prevas.dk<http://www.prevas.dk/> ___________________ [Linkedin]<https://www.linkedin.com/company/prevasdenmark/> [Facebook] <https://www.facebook.com/prevasdenmark/> [Instagram] <https://www.instagram.com/prevasdenmark/> [YouTube] <http://www.youtube.com/user/Prevas100>

4 months, 4 weeks

2
3
0 0

Feedback requested: Dynamic provisioning data configuration for STM board b_u585i-iot02a

by Benjamin GROLLEAU

Dear TF-M maintainers, I am currently developing an application using the STM board b_u585i-iot02a (target: b_u585i_iot02a/stm32u585xx/ns). As mentioned in this issue<https://github.com/zephyrproject-rtos/zephyr/issues/92670>, , the provisioning data is currently statically programmed. Instead of changing this hardcoded data directly, I created a jinja2 template and a generation script based on the original file. This follows the same pattern used in trusted-firmware-m/platform/ext/common/provisioning_bundle/CMakeLists.txt. This approach works well locally, but I would like some feedback to ensure it meets the project's standards before opening a PR. First, what are your thoughts on this method? Should this feature be made available for all STM boards, or is it better to restrict it to the b_u585i-iot02a for now? Additionally, I am currently passing variables such as huk, iak, and boot_seed from my local project's CMakeLists.txt. If they are not provided, the script simply falls back to the default hardcoded values. Thank you in advance for your time and guidance. Best regards, ——— Benjamin Grolleau benjamin.grolleau(a)outlook.com

5 months

1
0
0 0

TF-M CI failures

by Anton Komlev

Hello, TF-M CI is currently failing in most builds due to a documentation issue. The documentation was recently upgraded and now requires additional Python components in Docker image. We are aware of the issue and are working on fixes. Best regards, Anton

5 months

1
1
0 0

Short enums and short wchar

by Bohdan.Hunko＠infineon.com

Hi all, Currently TFM specifies -fshort-wchar and -fshort-enums There previously was a discussion about this in https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.… The decision was to remove these flags – which was done in https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6186 But then fix was reverted in https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6349 because: Removing the -fshort-wchar flag will cause link error with RTX library while using armclang and debug mode. Now we faced same issue when linking some of our prebuilt crypto libraries. Since RTX libraries ware prebuilt by TFM maintainers (prebuilt RTX libs are not part of CMSIS RTX) – I believe it is better to rebuild them without -fshort-wchar and -fshort-enums and remove these flags in TFM. Does TFM team still have a possibility to rebuild these RTX libs? Does this change make sense to TFM community? 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>

5 months

5
11
0 0

New TF-M m maintainer

by Anton Komlev

Hi Everyone, I am glad to announce the new maintainer of TF-M project: * Nicola Mazzucato aka nicola-mazzucato-arm <nicola.mazzucato(a)arm.com<mailto:nicola.mazzucato@arm.com>> Thank you, Nicola, for agreeing to maintain the project. All the best, Anton

6 months

1
0
0 0

New Clang/LLVM Toolchain Support Announcement

by Anton Komlev

Hello, I am thrilled to announce the support of new Clan/LLVM toolchain, freely available here: https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm. This extends a suite of powerful tools designed to enhance your development experience and boost productivity. Key Features: * Offers Clang frontend * Available for Linux, Windows and macOS * Builds TF-M binaries for all Arm targets * Secure side built without libc and picolib libraries, while both are available to Bootloader and Non-Secure side Important notes: * Floating point support is not verified * MVE is not supported yet * This has been verified with version v18.1.3 of the toolchain. We're excited for you to try out the new toolchain support and look forward to your feedback. The use of the toolchain_CLANG.cmake is the same as all other toolchains. I plan to present the new toolchain and compare it with the existing tools in one of the upcoming TF-M forums. Meanwhile I encourage the platform owners to include the new toolchain support using arm platforms as a reference. The relevant changes are in this chain: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34351 There is ongoing discussion on the best name for the toolchain to avoid possible confusion. Should it be Clang as now, LLVM, or even LLVMClang? Please share your opinion. Thanks, and best regards, Anton.

6 months

2
2
0 0

TF-M releases v2.1.3 and v2.2.1

by Anton Komlev

Hello, I'm pleased to announce the availability of TF-M releases v2.1.3 and v2.2.1. These are maintenance releases that address security vulnerability TFMV-9<https://trustedfirmware-m.readthedocs.io/en/latest/security/security_adviso…> along with several bug fixes identified since the previous release. For full details, please refer to the v2.1.3<https://trustedfirmware-m.readthedocs.io/en/tf-mv2.1.3/releases/2.1.3.html> and v2.2.1<https://trustedfirmware-m.readthedocs.io/en/tf-mv2.2.1/releases/2.2.1.html> release notes. A sincere thank-you to everyone who contributed, reviewed, or tested these releases. Best regards, Anton

6 months

3
4
0 0

Weird behavior of static-checks job

by Bohdan.Hunko＠infineon.com

Hi All, I se that http://ci.trustedfirmware.org/job/tf-m-static-checks/3233/consoleFull has FAILURE in the log, but the job passed: Include order test: FAILURE (warning) Additionally there are some other errors – a suspect that they may lead to this weird behavior: 22:23:00 + ./tf-m-ci-scripts/jenkins/verify.py --category static --value 1 --verify-name static-checks --user **** 22:23:01 Error posting to verify-status: 404 22:23:01 Not found: verify-status~verifications 22:23:01 22:23:01 Could not check if verify-status plugin is installed Is this expected? 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>

6 months

2
1
0 0

Build error for PSE84

by Chris.Brand＠infineon.com

Hi, I recently started seeing a build error for PSE84. "git bisect" tells me that it was introduced in c2fc818e. The error is from cmake, complaining about a circular dependency. The error message itself is extremely long, so I've attached it as a separate file. Chris

6 months

3
3
0 0

MCUBOOT_USE_PSA_CRYPTO : default value

by Ronan GABOU

Hello, As latest TFM version now supports MbedTLS 4.0 which use TF PSA CRYPTO (I understood only PSA API are available and no more mbed API) Don't you think that the default value for MCUBOOT_USE_PSA_CRYPTO in file : \trusted-firmware-m\bl2\ext\mcuboot\mcuboot_default_config.cmake should be ON instead of OFF ? Thank you. Ronan, [Shape, rectangle Description automatically generated] Ronan GABOU MDRF / Embedded Processing / General Purpose and Automotive MCU / Ecosystem / Security STMicroelectronics 134 avenue Aristide Briand, 92120 Montrouge, France This communication is confidential and intended solely for the addressee(s). If you are not the intended recipient, you should not review, retain, copy or distribute the e-mail itself or the information it contains. In such case, we kindly request you notify the sender by replying to this transmission and delete the message without disclosing it. Thank you! [cid:image002.png@01DC99E8.84F4A440]<https://www.facebook.com/STMicroelectronics.NV/> [cid:image003.png@01DC99E8.84F4A440] <https://twitter.com/st_world> [cid:image004.png@01DC99E8.84F4A440] <https://www.linkedin.com/company/stmicroelectronics/> [cid:image005.png@01DC99E8.84F4A440] <https://www.instagram.com/stmicroelectronics.nv/> [cid:image006.png@01DC99E8.84F4A440] <https://www.youtube.com/user/STonlineMedia> ST online: www.st.com

6 months, 1 week

2
1
0 0

PSA arch tests with new PSA crypoto headers build issues

by Bohdan.Hunko＠infineon.com

Hi all, I am trying to build psa-arch-tests for the latest master but I am getting these king of build errors: error: unknown type name 'psa_key_handle_t'; did you mean 'psa_handle_t'? 23 | static psa_key_handle_t public_key_handle; From what I can tell – psa arch tests have not yet been adapted to new PSA crypto headers. Am I correct? When can we expect this change to be available? 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>

6 months, 1 week

2
2
0 0

Race condition in SPM scheduler lock logic

by Bohdan.Hunko＠infineon.com

Hi all, I have found a bug in SPM scheduler lock logic – this bug is extremely hard to reproduce as it requires precise conditions and timings, but here is the description of the bug scenario: 1. Partition A calls psa_wait to wait for a signal (this signal is going to be asserted by FLIH IRQ later) 2. Currently signal is not asserted, no other partition is runnable, thus SPM marks this signal as being awaited and then schedules idle_thread 3. idle_thread calls psa_wait to poll SPM * psa_wait calls tfm_arch_thread_fn_call * tfm_arch_thread_fn_call calls backend_abi_entering_spm * backend_abi_entering_spm calls arch_acquire_sched_lock * arch_acquire_sched_lock sets scheduler_lock = SCHEDULER_LOCKED * psa_wait (called by idle_partition) is being processed up to the point of backend_abi_leaving_spm * backend_abi_leaving_spm calls arch_release_sched_lock * here is where very sneaky the bug happens * arch_release_sched_lock executes following assembly instructions i. "ldr r1, =scheduler_lock \n" "ldr r0, [r1, #0] \n" ii. At this point r0 holds scheduler_lock is = SCHEDULER_LOCKED iii. After these instructions are executed FLIH interrupt arrives * FLIH handler asserts signal (which should unblock execution of the Partition A) * spm_handle_interrupt calls backend_assert_signal * backend_assert_signal does if (p_pt->signals_asserted & p_pt->signals_waiting) and returns STATUS_NEED_SCHEDULE * spm_handle_interrupt calls arch_attempt_schedule * arch_attempt_schedule checks value of scheduler_lock (which is SCHEDULER_LOCKED) and sets scheduler_lock= SCHEDULER_ATTEMPTED * Interrupt returns iv. Execution continues, now scheduler_lock is = SCHEDULER_ATTEMPTED But the next line of code in arch_release_sched_lock is "movs r2, #"M2S(SCHEDULER_UNLOCKED)" \n"/* Unlock scheduler */ This effectively overwrites scheduler_lock from SCHEDULER_ATTEMPTED to SCHEDULER_UNLOCKED This means that following SRM scheduling logic will not trigger PendSV and just return to idle_partition – effectively resulting in a hang of a system. Looks like the solution is to wrap lock logic in critical section. But may be there is other things that can be done to better fix this issue. Let me know if there are other details that may be helpful to fix this bug. 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>

6 months, 2 weeks

6
21
0 0

TF-M transition to TF-PSACrypto

by Anton Komlev

Hi everyone, We are happy to announce that TF-M has transitioned to a standalone PSA Crypto component (TF-PSACrypto), a major milestone in the project’s development. TF-PSACrypto provides a reference PSACrypto implementation that is separated from the MbedTLS project. There are a few known issues, including platform support, which we expect to address before the next TF-M release. Thanks to everyone involved in the development, review and testing, especially the PSA Crypto team for releasing TF-PSACrypto and David Vincze for adapting TF-M to it. As always, we welcome feedback from the community. Best regards, Anton

6 months, 2 weeks

1
0
0 0

IAR build seems to be broken

by Bohdan.Hunko＠infineon.com

Hi all I see that https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/44534 added tfm_s_build_flags for all the compilers except IAR After version update - in our CI we see: Fatal error[Ms007]: could not open file "libtfm_s_build_flags.a" Is this intentional change or IAR file was just missed and the change should also be added for IAR? 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>

6 months, 3 weeks

4
6
0 0

Conflicted ADAC Configuration

by 김종혁

Hi. Anton Komlev. I'm phillip kim (jonghyeok kim). I have posted a new thread on https://lists.trustedfirmware.org/ But, I can't find my thread. I have heard this website had some problem. The thread i posted is below. ================================================================================================================= Hello all, I'm developing the RSE Firmware based on rdv3r1. And I'm trying to use ADAC feature. I found conflicted ADAC Configuration. Below file, the adac is app rot. \tf-m\cmake_build\rdv3r1\0\lib\ext\tf-m-extras-src\partitions\adac\CMakeLists And Below file, the adac is psa rot. \tf-m\cmake_build\rdv3r1\0\lib\ext\tf-m-extras-src\partitions\adac\tfm_adac.yaml Please explain about each two files. 1) Platform (arm neoverse RDV3R1 (RSE)) repo init -u https://git.gitlab.arm.com/infra-solutions/reference-design/infra-refdesign-... -m <manifest-file-name> -b refs/tags/<RELEASE_TAG> --depth=1 repo sync -c -j $(nproc) --fetch-submodules --force-sync --no-clone-bundle manifest file: pinned-rdv3r1.xml release tag: refs/tags/RD-INFRA-2025.07.03 2) Enabling the ADAC Parameter set(PLATFORM_PSA_ADAC_SECURE_DEBUG      TRUE       CACHE BOOL      "Whether to use psa-adac secure debug.") set(PLATFORM_PSA_ADAC_VERSION           "cbd17d8"   CACHE STRING    "The version of psa-adac to use.") set(TFM_EXTRAS_REPO_EXTRA_PARTITIONS    "adac;measured_boot;delegated_attestation;dice_protection_environment;scmi" CACHE STRING "List of extra secure partition directory name(s)") set(TFM_EXTRAS_REPO_EXTRA_MANIFEST_LIST "partitions/adac/adac_manifest_list.yaml;partitions/measured_boot/measured_boot_manifest_list.yaml;partitions/delegated_attestation/delegated_attestation_manifest_list.yaml;partitions/dice_protection_environment/dpe_manifest_list.yaml" CACHE STRING "List of extra secure partition manifests") set(TFM_PARTITION_ADAC      ON        CACHE BOOL      "Whether to use psa-adac secure debug.") 3) Build Command ./build-scripts/build-test-uefi.sh -p rdv3r1 build Thanks Best Regards Phillip ================================================================================================================= Thanks

6 months, 3 weeks

2
1
0 0

Upstreaming of MISRA fixes

by Bohdan.Hunko＠infineon.com

Hi, In our local copy of TFM we are running Coverity tools which performs MISRA, CERT-C and CODING static analysis checks on TFM codebase (I will refer to this as MISRA fixes for simplicity). During our development we did a bunch of fixes for the violations (not all rules but still significant number of changes). Most of these changes are small (e.g. U/UL postfixes, fixed width types usage, header file fixes etc…). When we do version updates or generally port code between upstream and local copy of TFM we have to deal with merge conflicts in these lines effected by MISRA fixes. To avoid these issues we would like to push these fixes upstream. There are quite a few changes and having everything in one patch will really simplify our work as we would not have to divide the changes. We would like to know whether creating one bigger patch with all the changes would be acceptable for the 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>

6 months, 3 weeks

4
5
0 0

[RD-V3 / rdv3r1] Question regarding Firmware Update Service support

by 박진국

Hello everyone, I am inquiring about the Firmware Update (FWU) service configuration on the *rdv3r1* (Neoverse RD-V3) platform. While building TF-M for the rdv3r1 target, I noticed that the *TFM Firmware Update Partition* is missing from the Secure Partitions list, even though I enabled the relevant CMake flags. Upon investigation, it seems that the build system is using the platform-specific manifest list located at: /tf-m/platform/ext/target/arm/rse/neoverse_rd/common/manifest/tfm_manifest_list.yaml Instead of the generic tf-m/tools/tfm_manifest_list.yaml. The issue is that the platform-specific manifest list appears to lack the definition for the FWU partition. Consequently, the files under generated/secure_fw/partitions/firmware_update/auto_generated are not being generated. Could you please clarify if the Firmware Update Service is currently not supported on the Neoverse RD environment? Or is there a specific configuration required to enable it? Thank you. Best regards, *JK Park*

7 months

2
1
0 0

Re: Handling the SAM partial write

by 김륜현

It seems that something issue occurs in mailing system. Anyway, i checked Amjad's answer in "Re: TF-M Digest, Vol 87, Issue 11".  Also, i checked M-AXI that can issue 64bit transaction for normal memory in Cortex-M55 TRM. As you mentioned, the core performs 32bit write-back and actual write to SRAM is performed as 64bit transaction using the cache and M-AXI between the 32bit core and the SRAM. But, another issue remains  Crypto Cell-312 internal DMA has hardware fixed 32bit data width. It raise partial write event when doing decryption to provisioning data. Example for this issue can be founded in validate_and_unpack_encrypted_bundle()(a)bl1_provisioning.c. To transfer decrypted output to SRAM, it uses internal DMA in CC312. Should i apply any way to workaround such as no using CC312 DMA or modifying bus width in our situation? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: 김륜현 <winxp4333(a)adtek.co.kr> 받는 사람: tf-m(a)lists.trustedfirmware.org 날짜: 2026-01-09 14:40:45 제목: Handling the SAM partial write Hi all, I'm developing the RSE Firmware based on rdv3r1. I have a concern about the SAM(Security Alarm Manager). Refering to TRM and codes, for the handling SRAM partial write to sets a correct ECC value, it read of 64 bits from the captured address(SAM.VMPWCAn) and write the value back to memory at the captured address. After that, it clears the SAM captured address register and SAM event. In that scheme, for the 32bit architecture CM55, what correct it everytime seems very overhead and burden if using a SRAM area as data region like stack, heap. Because 32bit access frequently occurs in 32bit architecture. Should we avoid using SRAM as data region even though i have found the cases of using SRAM as data region like? Best Regards RH Kim

7 months

2
1
0 0

Issue with absolute paths in exported targets

by Bohdan.Hunko＠infineon.com

Hi all, I have noticed an issue with absolute paths in exported targets: Background: 1. During Secure build some header file paths are added to include directories of tfm_config (and some other targets) – for example TARGET_CONFIG_HEADER_FILE, PROJECT_CONFIG_HEADER_FILE 2. Then tfm_config is exported to install directory and is used in Non-Secure build There are several issues here: 1. In Non-Secure build exported tfm_config uses absolute paths that ware defined during secure build. This is an issue as NS-interface (api_ns folder) may be built on another machine. 2. Also looking into api_ns folder – I don’t see those files being exported (for example TARGET_CONFIG_HEADER_FILE, PROJECT_CONFIG_HEADER_FILE are not exported to api_ns) * Looking into a code I was able to identify at least these defines that are effected (but list may be longer): i. TARGET_CONFIG_HEADER_FILE ii. PROJECT_CONFIG_HEADER_FILE iii. MBEDTLS_PSA_CRYPTO_CONFIG_FILE iv. MBEDTLS_CONFIG_FILE Is there a plan to somehow solve this issue? If so, then what is the schedule on it? 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>

7 months

2
3
0 0

Re: TF-M Digest, Vol 87, Issue 11

by Amjad Ouled-Ameur

Hi RyunHyeon, Thanks for raising this, your understanding is correct. On RSE with ECC-protected SRAM, partial writes (e.g. 32-bit stores) cannot update ECC atomically. When SAM partial-write detection is enabled, the firmware must perform a read–modify–write of the full ECC granule (64 bits) to recompute and restore a valid ECC value. Doing this in software for every partial access would indeed be prohibitively expensive, especially for stack and heap usage where 32-bit accesses are very frequent on Cortex-M55. To avoid this overhead while keeping SAM enabled, the recommended approach is to place a cache between the Cortex-M55 and the SRAM. The CPU can continue to issue 32-bit accesses, while the cache aggregates them and performs aligned 64-bit transactions toward SRAM. From the SRAM/SAM point of view, accesses are full-width and generate valid ECC, so SAM partial-write events are avoided in the common case. With this setup, SRAM can safely be used as a normal data region, without the performance penalty you described. Disabling SAM or avoiding SRAM for data is not the intended solution. I hope this clarifies the design intent. Regards, Amjad Amjad Ouled-Ameur Senior Software Engineer amjad.ouled-ameur(a)arm.com 110 Fulbourn Rd, Cambridge CB1 9NJ [A black letter r with white background Description automatically generated]<https://www.arm.com/> [A black letter f on a white background Description automatically generated]<https://www.facebook.com/Arm> [A black and white logo Description automatically generated]<https://www.linkedin.com/company/arm> [A black and white logo Description automatically generated]<https://www.instagram.com/arm/> [A black x with white lines Description automatically generated]<https://x.com/Arm> [A black and white play button Description automatically generated]<https://www.youtube.com/user/Armflix> ________________________________ Date: Fri, 9 Jan 2026 14:40:45 +0900 (KST) From: 김륜현 <winxp4333(a)adtek.co.kr> Subject: [TF-M] Handling the SAM partial write To: <tf-m(a)lists.trustedfirmware.org> Message-ID: <1299976795.188898.1767937245869@gwsrv> Content-Type: multipart/alternative; boundary="----=_Part_64610_764352995.1767937245794" Hi all, I'm developing the RSE Firmware based on rdv3r1. I have a concern about the SAM(Security Alarm Manager). Refering to TRM and codes, for the handling SRAM partial write to sets a correct ECC value, it read of 64 bits from the captured address(SAM.VMPWCAn) and write the value back to memory at the captured address. After that, it clears the SAM captured address register and SAM event. In that scheme, for the 32bit architecture CM55, what correct it everytime seems very overhead and burden if using a SRAM area as data region like stack, heap. Because 32bit access frequently occurs in 32bit architecture. Should we avoid using SRAM as data region even though i have found the cases of using SRAM as data region like? Best Regards RH Kim

7 months, 1 week

1
0
0 0

Handling the SAM partial write

by 김륜현

Hi all, I'm developing the RSE Firmware based on rdv3r1. I have a concern about the SAM(Security Alarm Manager). Refering to TRM and codes, for the handling SRAM partial write to sets a correct ECC value, it read of 64 bits from the captured address(SAM.VMPWCAn) and write the value back to memory at the captured address. After that, it clears the SAM captured address register and SAM event. In that scheme, for the 32bit architecture CM55, what correct it everytime seems very overhead and burden if using a SRAM area as data region like stack, heap. Because 32bit access frequently occurs in 32bit architecture. Should we avoid using SRAM as data region even though i have found the cases of using SRAM as data region like? Best Regards RH Kim

7 months, 1 week

2
1
2 0

Question about HW OTP Keys (KCE_CM, KP_CM, KCE_DM, KP_DM) usage in RD-V3-R1

by 김준영

Hello, I am an RSE firmware developer currently working on the Neoverse Reference Design Platform (RD-V3-R1). I have a few questions regarding the four hardware keys stored in OTP: KCE_CM, KP_CM, KCE_DM, and KP_DM. My understanding is based on the following documents: - Arm® Lifecycle Manager Version 1.0 Specification   (Issue 02, 107616_0000_02_en) - RD-V3-R1 reference documentation – RSE / Keys section   (https://neoverse-reference-design.docs.arm.com/en/rd-infra-2025.07.03/share…) According to the LCM specification, KP_CM and KP_DM are described as "Provisioning Keys". However, in the RD-V3-R1 TF-M v2.1.1 implementation, these keys do not appear to be used. Additionally, KCE_DM is documented as "DM code encryption key, currently unused". Q1. Is it valid and compliant with the intended reference design and     specification to provision KP_CM, KP_DM, and KCE_DM with dummy values? Regarding KCE_CM: Both the LCM specification and the RD-V3-R1 documentation describe KCE_CM as a "Code Encryption Key", but I could not find a clear specification defining which OTP assets are expected to be encrypted using this key. In the current TF-M implementation, KCE_CM is used to encrypt: - KEY_BL2_ENCRYPTION - KEY_SECURE_ENCRYPTION - KEY_NON_SECURE_ENCRYPTION Q2. Is KCE_CM intended to protect exactly these three items?     If so, which specification or document defines this behavior? Q3. The LCM specification states that KCE_CM should be used for     key derivation purposes only.     However, in TF-M, KCE_CM does not appear to be used as an input to a KDF at all;      instead, it is used directly as an AES encryption key for protecting OTP-related assets.     Is this direct usage considered compliant with the intended LCM     security model, or is a product-grade implementation expected to     introduce an explicit key derivation step before using KCE_CM     for encryption? Any clarification on the design intent would be greatly appreciated. Thank you for your time and support.

8 months

1
0
0 0

Re: Several Questions related to RSE Provisioning

by 김태훈

Hi Jackson, Thanks for fast response. I shall combine the points requested in your previous reply with the questions that have arisen while reviewing the code since then, and respond accordingly. 1. TF-A has APIs for using Host RoTPKs stored in RSE TF-M. These calls are classified by enum in platform/ext/target/arm/rse/common/platform_builtin_key_loader_ids.h. Then I found out that some changes happened in this code. (If uploaded images aren't shown, please let me know. This image is about code change of platform_builtin_key_loader_ids.h.) That's the point that I asked before. However, in this code, RSE_ROTPK_CM_HOST_AMOUNT and RSE_ROTPK_DM_HOST_AMOUNT are only defined in platform/ext/target/arm/rse/common/subplatform_pal_default_config/rse_rotpk_config.h. I understand that one CM ROTPK and two DM ROTPK substitute previous Host RotPKs, but don't understand why. I think this part is for Chain-of-Trust in whole firmware stack including TF-A, TF-M and TF-RMM. - Is it acceptable to use that ROTPKs as trust anchors for the Host's CoT, as was done previously? - Is this definition used as-is during the build process, located in the subplatform folder for the quantity of the relevant ROTPK? - What is the purpose of the 'subplatform' definition? 2. There were several CCA assets in the provisioning bundle. These assets include implementation identifier, platform definition, and verification service URL. I can't find field for these assets in the OTP layout in TF-Mv.2.2.2.  Have they completely disappeared? Otherwise, how can it be set? I'm a bit embarrassed that they're not visible. I'm always grateful for your efforts in maintaining this project. I realise that waiting for the next version of RDINFRA might actually be the better answer, but I wish to understand the code without relying on that. Thank you. ----- 원본 메시지 ----- 보낸 사람: Jackson Cooper-Driver via TF-M <tf-m(a)lists.trustedfirmware.org> 받는 사람: 김태훈 <gth1919@adtek.co.kr>,tf-m@lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> 날짜: 2025-12-12 19:28:53 제목: [TF-M] Re: Several Questions related to RSE Provisioning Hi TH Kim, Thanks for getting in touch, please see my answers below. Thanks, Jackson From: 김태훈 via TF-M <tf-m(a)lists.trustedfirmware.org> Date: Thursday, 11 December 2025 at 16:40 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Several Questions related to RSE Provisioning Hello, I'm a RSE firmware developer for Arm Neoverse V3 core. I am currently reviewing the code to upgrade the version of TF-M used in our product from 2.1.1 to 2.2.2. In this process, I have a few questions and am sending this email. 1. In the previous TF-Mv2.1.1, there were dummy files for the data structure of the bundle to be provisioned to the OTP during CM and DM state. I have discovered that the method for creating the bundle has changed significantly in the TF-Mv2.2.2, but there are still parts I cannot locate: Host RoTPKs (for secure, non-secure, and CCA). This parts were provisioned during the DM provisioning process in the TF-Mv2.1.1 with a size of each 96B. I am curious how this parts are implemented in 2.2.2. >> In TF-Mv2.2.2, we currently only provision a small number of the CM ROTPK slots and do not provision any DM ROTPKs. It is possible that we might decide to add more ROTPKs in the future for use by the host, but that is not currently implemented. The keys themselves would be specific to the platform. 1-1. When TF-A sends a PSA call to the RSE, it distinguishes which Host RoTPK to request from the RSE via persistent key identifiers. I am also curious about how this aspect is handled within the RSE TF-M. (Should this fall outside the scope of the TF-M project, please disregard this point.) >> Can you point me to the code that does this in TF-A and then I can help you trace it back to how the RSE handles this? 2. In the latest TF-Mv2.2.2, as mentioned earlier, the data structure for the Provisioning value appears to have undergone significant changes. Reviewing the code, I observed that the CM and DM Provisioning values contain multiple RoTPK areas. Some are used to verify the signatures of the BL2 and PE, but many are not. Are the unused fields simply reserved for future use, or spares? Each area can contain up to four RoTPK Hashes, and in the case of DM, there are as many as eight such areas, which appears to be a significant waste of space. I would like to understand what scenarios this design anticipates. >> The intention of the additional ROTPK arrays is to allow for key revocation should a key become compromised. Should this be required, then the entire array (of up to four hashes) will be revoked and a new array provisioned. Additional unused key slots within a single ROTPK array are reserved for potential future use. 3. To obtain information about RSE, I have been referring to the content of the official documentation. However, when comparing it to the current latest release, the documentation appears to remain based on a previous version. For example, For example, despite the code for the GPIO signal indicating the status for RSE Provisioning having been removed in the latest version, the documentation still retains that content. I would like to know specifically whether there are plans to update this documentation. >> Apologies for this, we have been slow to update the RSE public documentation. Please do continue to point out any issues and we will update them. We are updating the docs piecemeal and it is a slow process. Please bear with us on this. Truthfully, I suspect all these questions could be answered by better understanding the code, which makes me hesitant to send an email. However, due to various constraints, I kindly ask for your understanding regarding my posting this query on the forum. Thank you. Best Regard, TH Kim Best Regard, TH Kim

8 months

2
1
0 0

-Warray-parameter issue : tool version to update

by Ronan GABOU

Hello All, I hope it is the correct process to inform you than I got an issue and how I solved it I was using tools GNU Arm compiler version minimum 10.3.2021.10 as mentioned on TFM web But with latest TFM on main branch I had a build error dur to -Warray-parameter (only with GNU it is ok with IAR and CLANG that seems normal) I moved to GNU 14.3.1 (arm-gnu-toolchain-14.3.rel1-mingw-w64-x86_64-arm-none-eabi.exe as I’m using windows) and my problem was solved 😊 So I think the minimal version on TFM web is no more valid. Since: [cid:image007.png@01DC6B7E.96AB43D0] Regards, Ronan, [Shape, rectangle Description automatically generated] Ronan GABOU MDRF / Embedded Processing / General Purpose and Automotive MCU / Ecosystem / Security STMicroelectronics 134 avenue Aristide Briand, 92120 Montrouge, France This communication is confidential and intended solely for the addressee(s). If you are not the intended recipient, you should not review, retain, copy or distribute the e-mail itself or the information it contains. In such case, we kindly request you notify the sender by replying to this transmission and delete the message without disclosing it. Thank you! [cid:image002.png@01DC6B7E.415BF870]<https://www.facebook.com/STMicroelectronics.NV/> [cid:image003.png@01DC6B7E.415BF870] <https://twitter.com/st_world> [cid:image004.png@01DC6B7E.415BF870] <https://www.linkedin.com/company/stmicroelectronics/> [cid:image005.png@01DC6B7E.415BF870] <https://www.instagram.com/stmicroelectronics.nv/> [cid:image006.png@01DC6B7E.415BF870] <https://www.youtube.com/user/STonlineMedia> ST online: www.st.com

8 months

2
1
0 0

Upgrade TF-M to C11 standard

by Anton Komlev

Hello, I'd like to check with the community about upgrading the compilation standard from C99 to C11. The initial trial looks promising, as you can see here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/46212 Please let me know if your platform or project depends on C99 or if you would prefer to keep using it, and feel free to object to this upgrade. With no objections by Dec 21, I will merge the patch. Thanks, Anton

8 months, 1 week

1
0
0 0

Several Questions related to RSE Provisioning

by 김태훈

Hello, I'm a RSE firmware developer for Arm Neoverse V3 core. I am currently reviewing the code to upgrade the version of TF-M used in our product from 2.1.1 to 2.2.2. In this process, I have a few questions and am sending this email. 1. In the previous TF-Mv2.1.1, there were dummy files for the data structure of the bundle to be provisioned to the OTP during CM and DM state. I have discovered that the method for creating the bundle has changed significantly in the TF-Mv2.2.2, but there are still parts I cannot locate: Host RoTPKs (for secure, non-secure, and CCA). This parts were provisioned during the DM provisioning process in the TF-Mv2.1.1 with a size of each 96B. I am curious how this parts are implemented in 2.2.2. 1-1. When TF-A sends a PSA call to the RSE, it distinguishes which Host RoTPK to request from the RSE via persistent key identifiers. I am also curious about how this aspect is handled within the RSE TF-M. (Should this fall outside the scope of the TF-M project, please disregard this point.) 2. In the latest TF-Mv2.2.2, as mentioned earlier, the data structure for the Provisioning value appears to have undergone significant changes. Reviewing the code, I observed that the CM and DM Provisioning values contain multiple RoTPK areas. Some are used to verify the signatures of the BL2 and PE, but many are not. Are the unused fields simply reserved for future use, or spares? Each area can contain up to four RoTPK Hashes, and in the case of DM, there are as many as eight such areas, which appears to be a significant waste of space. I would like to understand what scenarios this design anticipates. 3. To obtain information about RSE, I have been referring to the content of the official documentation. However, when comparing it to the current latest release, the documentation appears to remain based on an previous version. For example, For example, despite the code for the GPIO signal indicating the status for RSE Provisioning having been removed in the latest version, the documentation still retains that content. I would like to know specifically whether there are plans to update this documentation. Truthfully, I suspect all these questions could be answered by better understanding the code, which makes me hesitant to send an email. However, due to various constraints, I kindly ask for your understanding regarding my posting this query on the forum. Thank you.Best Regard, TH Kim

8 months, 1 week

2
1
0 0

Test email-3 from PN

by Prasanth Nair

Test email-3 from PN

8 months, 1 week

1
0
0 0

Another Test from PN

by Prasanth Nair

Another Test from PN

8 months, 1 week

1
0
0 0

TF-M test message from PN

by Prasanth Nair

TF-M test message from PN

8 months, 1 week

1
0
0 0

TF-M Test Message

by Shaun Longhorn

All, We've had reports of people being unable to send messages to the TF-M list. If you are one of the people please could you send me a rough time, source address and subject for the failed message. Thanks, Shaun Longhorn Community Manager

8 months, 1 week

1
0
0 0

test message

by Anton Komlev

This is a test message because an issue with the mailing list was reported.

8 months, 1 week

1
0
0 0

Issue with absolute paths in exported targets

by Bohdan.Hunko＠infineon.com

Hi all, I have noticed an issue with absolute paths in exported targets: Background: 1. During Secure build some header file paths are added to include directories of tfm_config (and some other targets) – for example TARGET_CONFIG_HEADER_FILE, PROJECT_CONFIG_HEADER_FILE 2. Then tfm_config is exported to install directory and is used in Non-Secure build There are several issues here: 1. In Non-Secure build exported tfm_config uses absolute paths that ware defined during secure build. This is an issue as NS-interface (api_ns folder) may be built on another machine. 2. Also looking into api_ns folder – I don’t see those files being exported (for example TARGET_CONFIG_HEADER_FILE, PROJECT_CONFIG_HEADER_FILE are not exported to api_ns) * Looking into a code I was able to identify at least these defines that are effected (but list may be longer): i. TARGET_CONFIG_HEADER_FILE ii. PROJECT_CONFIG_HEADER_FILE iii. MBEDTLS_PSA_CRYPTO_CONFIG_FILE iv. MBEDTLS_CONFIG_FILE Is there a plan to somehow solve this issue? If so, then what is the schedule on it? 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>

8 months, 1 week

1
0
0 0

Updated invitation with note: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday from Thu 27 May 2021 to Wed 31 Dec (BST) (tf-m@lists.trustedfirmware.org)

by Shaun Longhorn

This event has been updated with a note: "The TF-M Technical Forum now runs on a monthly schedule in a time slot chosen to maximize participation based on recent attendance patterns. We recognise that time zones can be challenging, and we continue to review scheduling based on community needs. Everyone is welcome to join, and as always, recordings and notes will be available for those who can’t attend live." Changed: time TF-M Tech forum Every 4 weeks from 8am to 9am on Thursday from Thursday 27 May 2021 to Wednesday 31 Dec United Kingdom Time Location https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9253579… About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==…Topic: TF-M Tech forum - Asia Time Zone FriendlyTime: Nov 12, 2020 07:00 AM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 4, 2021, 5 occurrence(s)        Nov 12, 2020 07:00 AM        Dec 10, 2020 07:00 AM        Jan 7, 2021 07:00 AM        Feb 4, 2021 07:00 AM        Mar 4, 2021 07:00 AMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT09Meeting ID: 925 3579 4925Passcode: 414410One tap mobile+12532158782,,92535794925# US (Tacoma)+13462487799,,92535794925# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 925 3579 4925Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW Guests Don Harbin - creator tf-m(a)lists.trustedfirmware.org anton.komlev(a)arm.com leonardo.sandoval(a)linaro.org abdelmalek.omar1(a)gmail.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Reply for tf-m(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

8 months, 1 week

1
0
0 0

Synced invitation: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday from Thu 14 Sept 2023 to Wed 31 Dec (BST) (tf-m@lists.trustedfirmware.org)

by Shaun Longhorn

This email keeps the event up to date in your calendar. TF-M Tech forum Every 4 weeks from 8am to 9am on Thursday from Thursday 14 Sept 2023 to Wednesday 31 Dec United Kingdom Time Location https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9253579… About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==…Topic: TF-M Tech forum - Asia Time Zone FriendlyTime: Nov 12, 2020 07:00 AM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 4, 2021, 5 occurrence(s)        Nov 12, 2020 07:00 AM        Dec 10, 2020 07:00 AM        Jan 7, 2021 07:00 AM        Feb 4, 2021 07:00 AM        Mar 4, 2021 07:00 AMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT09Meeting ID: 925 3579 4925Passcode: 414410One tap mobile+12532158782,,92535794925# US (Tacoma)+13462487799,,92535794925# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 925 3579 4925Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW Guests Don Harbin - creator anton.komlev(a)arm.com leonardo.sandoval(a)linaro.org abdelmalek.omar1(a)gmail.com joanna.farley(a)arm.com tf-m(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

8 months, 1 week

1
0
0 0

Update to TF-M Technical Forum Scheduling

by Anton Komlev

Hi All, I wanted to inform you about a change to the TF-M Technical Forum meeting schedule. Previously, we held sessions every two weeks, alternating between Eastern and Western-friendly time zones to accommodate our global audience. After reviewing participation patterns we've decided to simplify the schedule to a monthly cadence, with meetings held in a Western-friendly time slot. We hope this update makes participation more predictable and better aligned with current engagement. Everyone is still very welcome to attend, and as always, recordings and notes will be available for those unable to join live. Best regards, Anton

8 months, 2 weeks

1
0
0 0

Technical Forum call - Sep 12 (East time zone).

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, Sep 12 at 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

8 months, 2 weeks

2
21
0 0

TFM_VERSION

by Chris.Brand＠infineon.com

I notice that TFM_VERSION_MANUAL gets set to "2.2.1" in both release/2.2.x and in main. Granted, the hash gets appended to make TFM_VERSION, and there's some reading of git tags involved that can override TFM_VERSION_MANUAL, but it still feels odd that both identify as the "same" version. Perhaps main should be flagged as being the "next" version as soon as the previous version branch has been created? So we would tag main as v2.3.pre or something. Either that or something that identifies as *not* being a regular release. Chris

8 months, 3 weeks

2
1
0 0

IAR + FIH issue

by Bohdan.Hunko＠infineon.com

Hi all, I am trying to build TFM with IAR with TFM_FIH_PROFILE=HIGH and I am facing the issue with the FIH labels. I see following errors: [ 98%] Linking C executable ../bin/tfm_s.axf Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_END_46_1"; in "main.o(libtfm_spm.a)", and "tfm_hal_platform.o(libtfm_spm.a)" Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_START_46_1"; in "main.o(libtfm_spm.a)", and "tfm_hal_platform.o(libtfm_spm.a)" Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_END_35_0"; in "tfm_hal_platform.o(libtfm_spm.a)", and "platform_svc_handler.o(libtfm_spm.a)" Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_START_35_0"; in "tfm_hal_platform.o(libtfm_spm.a)", and "platform_svc_handler.o(libtfm_spm.a)" I did some investigations and I believe I know the root cause: Looks like __COUNTER__ for IAR is unique only for a translation unit (.c file) - thus when 2 files have FIH call in same line with the same number of FIH calls before - it creates a label which overlaps with labels in other file. For example tfm_hal_platform.c in our case has first FIH CALL in line 46 (which creates label FIH_LABEL_FIH_CALL_END_46_1) but main.c in our code also has first FIH CALL in line 46 which also results in FIH_LABEL_FIH_CALL_END_46_1 label. The question is - how can we solve this issue? Any ideas I can try? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

8 months, 4 weeks

2
7
0 0

Upcoming TF-M Minor Releases: v2.1.4 and v2.2.2

by Anton Komlev

Hello, We're preparing two new minor releases: v2.1.4 and v2.2.2. Both releases update TF-M to include MbedTLS v3.6.5, which brings several vulnerability fixes and fix of the bug reported in v2.2.1. Following a successful dry-run test we'll publish Release Candidate (RC1) followed by the final release. As these are minor updates, we don't expect platform-specific testing, assuming the changes are platform-independent and that our CI coverage will be sufficient. However, please feel free to reach out if you have any concerns or foresee any platform impact. Thank you and best regards, Anton

9 months

1
0
0 0

AI Policy - Guidance on AI-assisted contributions

by Shaun Longhorn

All, Please be aware that today we have published our AI policy with Guidance on AI-assisted contributions. See the full details here: https://www.trustedfirmware.org/aipolicy/ Should you have any questions feel free to raise them. Thanks, Shaun Community Manager

9 months

1
0
0 0

Re: [Hafnium] Re: Gerrit scheduled maintenance: 8th November 8-12 UTC

by jerome.forissier＠linaro.org

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

9 months, 1 week

1
0
0 0

Re: Gerrit scheduled maintenance: 8th November 8-12 UTC

by saheer.babu＠arm.com

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

9 months, 1 week

3
2
0 0

TF-M with Zephyr port of MCUboot

by Ozer, Sadik

Hi TF-M team, In our product, we intend to use the vanilla MCUboot (specifically the Zephyr port) instead of the version bundled with Trusted Firmware-M (TF-M). Since TF-M is optional for our use case, but MCUboot is a mandatory component, we prefer to decouple the two. Seems there are some provisioning related items that need to be handled in vanilla MCUboot for this type of usage. We would like to know if you foresee any security concerns or risks associated with this approach? Is this an expected of a usage? Any feedback for this type of usage would be appreciated. Thanks Sadik

9 months, 2 weeks

2
1
0 0

Open CI testing infrastructure is currently experiencing issues

by Anton Komlev

Hello, The Open CI testing infrastructure is currently experiencing issues due to an FVP licensing problem. Image builds remain operational but FVP-based tests are failing, which causes all build jobs to be marked as failed. The Open CI team is actively working to resolve the issue. An update will be shared once normal operation is restored. Thanks, Anton

9 months, 2 weeks

1
1
0 0

FIH code sharing

by Chris.Brand＠infineon.com

Hi, Currently TF-M and mcuboot have some "common" FIH code (see for example commit 0a74c1ea8a0c0783a2914d87cd2e88b677718a2e that copied fih.{c|h} from mcuboot. There are also multiple copies of fih.h within the TF-M repo (lib/fih/inc and bl2/ext/mcuboot/include). Are there any plans to avoid having copies of that code? Maybe to split the FIH library into its own repo that can be used by both TF-M and mcuboot? Thanks, Chris

9 months, 2 weeks

2
1
0 0

Question on pka_ec_wrst_smul_scap.c in CryptoCell3xx Runtime

by Sato, Masaki

Hi TFM Developer Forum Organizer, I'm currently integrating the CryptoCell3xx Runtime code for ECDSA hardware acceleration and have a question regarding the implementation. I'm not entirely sure if this is the right list to post to - perhaps it belongs in mbed-tls or psa-crypto instead - so please forgive me and suggest the right list if this is not the appropriate forum. I noticed that the repository contains two variants of pka_ec_wrst_smul: one under no_scap and another under scap, located in /lib/ext/cryptocell-312-runtime/codesafe/src/crypto_api/pki/ec_wrst/. From the filenames and comments, it appears that scap.c is the Side-Channel Attack (SCA)-resistant version, and would therefore be preferred for end-user products where stronger security is prioritized over performance. However, in the current version of pka_ec_wrst_smul_scap.c from the main open-source branch, I found a couple of apparent typos/bugs that cause compilation errors: Line 239: should probably be PkaAddJcbJcb2Mdf(EC_SIGN_REG_XS, EC_SIGN_REG_YS, EC_SIGN_REG_ZS, EC_SIGN_REG_TS, EC_SIGN_REG_XS, EC_SIGN_REG_YS, EC_SIGN_REG_ZS, EC_SIGN_REG_X2, EC_SIGN_REG_T2, EC_SIGN_REG_Z2); (currently missing the leading "P".) Lines 389 and 391: the output parameters are declared as const, which seems incorrect. For example: CCError_t PkaEcWrstScalarMult(const CCEcpkiDomain_t *pDomain, /*!< [in] Pointer to EC domain. */ const uint32_t *scalar, /*!< [in] Pointer to the scalar buffer. */ uint32_t scalSizeInWords, /*!< [in] Size of the scalar in 32-bit words. */ uint32_t *inPointX, /*!< [in] Pointer to input point X coordinate. */ const uint32_t *inPointY, /*!< [in] Pointer to input point Y coordinate. */ const uint32_t *outPointX, /*!< [out] Pointer to output point X coordinate. */ The const qualifier on the output parameters seems unintended and rather for inPointX. Because of these issues, it seems this file might not have been recently reviewed or tested. So, my questions are: 1. Is the CryptoCell312 Runtime actively maintained and tested in a specific branch where these typos/bugs are already fixed? If so, could you please share which branch that is? 2. If not, it seems that CMake currently only selects the no_scap variant. Does this mean the scap variant is not actively maintained or tested, and therefore not recommended for production use due to higher risk? Thanks in advance for your help and clarification. Best regards, Masaki Sato (P.S. I have sent this message from proofpoint TFM list by "Start a new thread" button. However, I don't see a record on the "posting activity" under my account profile nor active discussion list. Pardon me, but I'm a newbie to this forum, so please forgive me to send the same message by email. ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.

9 months, 2 weeks

3
3
0 0

Gerrit scheduled maintenance: 8th November 8-12 UTC

by saheer.babu＠arm.com

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

9 months, 2 weeks

1
0
0 0

TF-M v2.3.0 is postponed to Q2 2026

by Anton Komlev

Hello, I would like to inform the community that the TF-M v2.3.0 release has been postponed to April 2026 in order to incorporate the forthcoming PSA-Crypto LTS release, anticipated in Q1 2026. This decision is intended to ensure improved long-term alignment between two projects. I apologize for any inconvenience the delay may cause and appreciate your understanding. Best regards, Anton

9 months, 3 weeks

1
0
0 0

Enable PLATFORM_PSA_ADAC_SECURE_DEBUG

by 김종혁

Hello, I have already poted this. but, i can't find my thread. I’m trying to enable the PLATFORM_PSA_ADAC_SECURE_DEBUG. 1) Platform (arm neoverse RDV3R1 (RSE)) repo init -u https://git.gitlab.arm.com/infra-solutions/reference-design/infra-refdesign… -m <manifest-file-name> -b refs/tags/<RELEASE_TAG> --depth=1 repo sync -c -j $(nproc) --fetch-submodules --force-sync --no-clone-bundle manifest file: pinned-rdv3r1.xml  release tag: refs/tags/RD-INFRA-2025.07.03 2) Enabling the ADAC Parameter \\wsl.localhost\Ubuntu-22.04\home\phillip\251020_ws\tf-m\config\config_base.cmake I changed the parameter from FALSE to TRUE. set(PLATFORM_PSA_ADAC_SECURE_DEBUG      TRUE       CACHE BOOL      "Whether to use psa-adac secure debug.")   3) Build Command phillip@phillip3420:~/251020_ws$ ./build-scripts/build-tf-m.sh -p rdv3r1 -f uefi build 4) Error Message =============================================================================== -- Populating libpsaadac -- Configuring done (0.0s) -- Generating done (0.0s) -- Build files have been written to: /home/phillip/251020_ws/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-subbuild [1/9] Creating directories for 'libpsaadac-populate' [1/9] Performing download step (git clone) for 'libpsaadac-populate' Cloning into 'libpsaadac-src'... HEAD is now at 819a254 Platform: Fix prototype for crypto_hw_apply_debug_permissions [2/9] Performing update step for 'libpsaadac-populate' -- Already at requested ref: 819a254af6fb5eefdcef194ec85d2c7627451351 [3/9] No patch step for 'libpsaadac-populate' [5/9] No configure step for 'libpsaadac-populate' [6/9] No build step for 'libpsaadac-populate' [7/9] No install step for 'libpsaadac-populate' [8/9] No test step for 'libpsaadac-populate' [9/9] Completed 'libpsaadac-populate' CMake Error at cmake_build/rdv3r1/0/lib/ext/libpsaadac-src/target/trusted-firmware-m/config.cmake:12 (Message):   Platform arm/rse/neoverse_rd/rdv3r1 not supported. Call Stack (most recent call first):   cmake_build/rdv3r1/0/lib/ext/libpsaadac-src/CMakeLists.txt:34 (include) -- Configuring incomplete, errors occurred! +++ handle_error ++++ caller 0 +++ local 'callinfo=93 do_build ./build-scripts/build-tf-m.sh' +++ local script=./build-scripts/build-tf-m.sh +++ local lineno=93 +++ local 'func=93 do_build' +++ func=do_build +++ echo +++ echo -en '\e[1m\e[31mBuild failed: error while running do_build at line ' Build failed: error while running do_build at line +++ echo -en '93 in ./build-scripts/build-tf-m.sh for rdv3r1[rdv3r1]' 93 in ./build-scripts/build-tf-m.sh for rdv3r1[rdv3r1]+++ echo -e '[uefi].\e[0m' [uefi]. +++ echo +++ exit 1 =============================================================================== 5) My opinion TFM_PLATFORM_PATH is "/home/phillip/251020_ws/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-src/target/trusted-firmware-m/platform/arm/rse/neoverse_rd/rdv3r1" in my workpace. But, in the "/home/phillip/251020_ws/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-src/target/trusted-firmware-m/platform/arm/rse/" directory, there are only two folders, "common" and "tc". PLATFORM_PSA_ADAC_VERSION should be changed? (The RD-INFRA-2025.07.03 source code use PLATFORM_PSA_ADAC_VERSION as 819a254) I would be grateful for any advice or pointers from anyone familiar with this. Thanks Best Regards Phillip

9 months, 3 weeks

3
2
2 0

TFM fails to compile asm (.s) file for CM55 core

by Bohdan.Hunko＠infineon.com

Hi all, I see that https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/31942 changes the way ASM files are built for Clang, this seems to cause the issues in our build: I am trying to compile following file https://github.com/Infineon/mtb-dsl-pse8xxgp/blob/master/pdl/drivers/source… for cortex-m55<https://github.com/Infineon/mtb-dsl-pse8xxgp/blob/master/pdl/drivers/source…> CPU but I get following errors: armclang: error: armasm does not support CPU 'cortex-m55' armclang: error: armasm does not support FPU 'unknown' cmd.txt shows full compile command for this file. I suppose this is because -masm=armasm does not support CM55 core? Any ideas how to fix this? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

10 months

2
4
0 0

Rollback protection in Internal Trusted Storage

by Bojan Simoneta

Dear TF-M Community, I have a question regarding rollback protection in Internal Trusted Storage. Scenario: Recently we are seeing an increasing number of products which will come to market without internal Flash; together with this, there is also the requirement to store permanent keys using PSA key management APIs as psa_import_key, which will then in turn use Internal Trusted Storage as place where keys will be written. Considering these requirements there is a necessity to implement the Internal Trusted Storage in external Flash, which brings with it security challenges: the keys stored in external Flash would require confidentiality but also rollback protection. The encryption of ITS encryption was recently enabled as you can see in the following Pull request https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15096, but rollback protection is not yet implemented. Proposal: Our proposal would be to: - Add ITS rollback protection as optional feature, since it is not desired feature for product where the ITS storage is internal - Add rollback protection mechanism to Internal Trusted Storage functions relying on the NV counters APIs called from the platform layer, similar as is already done for Protected Storage Also, we are open to discuss any other proposal which would help us to fulfill the above requests (ITS in external Flash with still providing confidentiality and rollback protection). Thanks in advance for the answer and further guidance on the topic. KR, Bojan Simoneta Bojan Simoneta (He / Him / His) Principal Embedded SW Engineer Phone: +433124 299160 Email: bojan.simoneta(a)nxp.com<mailto:bojan.simoneta@nxp.com> [cid:image006.png@01DC347E.50852920] NXP Semiconductors Austria GmbH & Co KG | Mikronweg 1, 8101 Gratkorn | Austria | Sitz: Gratkorn, Österreich | Firmenbuchgericht: Landesgericht für ZRS Graz | Firmenbuchnummer: FN 541474 k | VAT: ATU76231908 Unless otherwise recorded in a signed, written agreement, all sales transactions by NXP are exclusively subject to NXP's Terms and Conditions of Commercial Sale ("NXP Terms") published at: www.nxp.com/profile/terms/index.html<http://www.nxp.com/profile/terms/index.html>. NXP explicitly rejects and disregards any terms and conditions of customer that add to, or differ from, NXP's Terms irrespective of when customer raises its terms. The information contained in this message is confidential. The message is intended solely for the addressee(s). If you are not the intended recipient, any use, dissemination, or reproduction is strictly prohibited and may be unlawful and you are asked to please contact the sender by return e-mail and destroy all copies of the original message.

10 months, 2 weeks

2
1
0 0

TF-M CI Coverity changes

by Matt Dalzell

Hi all, We are considering moving the TF-M Coverity scan (the results from https://ci.trustedfirmware.org/view/TF-M/job/tf-m-coverity/) to a private instance. I am sending this out to find out if anyone who is external to Arm uses these results, or would like to see the results in the future. If there is interest in keeping the public one working then we can have both the private and public ones running alongside each other to keep the results visible. Please let me know if you are a user of the current Coverity system, or wish to be able to view the results in the future so the jobs can be configured accordingly. If no interest is shown then the Coverity scan will be switched over to only the private instance. Thanks, Matt Dalzell - Arm

10 months, 2 weeks

1
0
0 0

GNU compiler update

by Matt Dalzell

Hello all, Today we have upgraded the version of Arm GNU Toolchain on the TF-M OpenCI to version 14.3rel1. We ask that you please update your local version to match this to allow for ongoing compatibility. If you have any questions or issues, please do not hesitate to let me know. Thanks, Matt Dalzell - Arm

10 months, 3 weeks

1
0
0 0

Re: CI infrastructure scheduled maintenance: 12th Sep 2025

by saheer.babu＠arm.com

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

11 months, 1 week

1
0
0 0

FW: CI infrastructure scheduled maintenance: 12th Sep 2025

by Joanna Farley

FYI From: Saheer Babu via Tf-openci <tf-openci(a)lists.trustedfirmware.org> Date: Wednesday, 10 September 2025 at 15:17 To: tf-openci(a)lists.trustedfirmware.org <tf-openci(a)lists.trustedfirmware.org> Subject: [Tf-openci] CI infrastructure scheduled maintenance: 12th Sep 2025 Hi all, We will be performing upgrade of the clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Friday, 12th Sep 2025 at 16:00 GMT+1. During this maintenance window, both services will be unavailable for approximately 4 hours. A follow-up email will be sent once the services are fully restored. Best regards, Saheer IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- Tf-openci mailing list -- tf-openci(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-leave(a)lists.trustedfirmware.org

11 months, 1 week

1
0
0 0

TF-M version reporting issue

by Anton Komlev

Hello, We've identified an issue with the TF-M versioning: it reports the wrong version from Git tags (showing v2.1.3 instead of the correct v2.2.1). As a temporary workaround, please set the version manually. We're working on a fix and will share updates as soon as possible. Best regards, Anton Komlev

11 months, 1 week

1
1
0 0

libpsaadac-populate build Tag error (PLATFORM_PSA_ADAC_SECURE_DEBUG)

by 박진국

Hello, I’m trying to enable the secure debug feature and configured TF-M as follows: 1) Configuration # ./config/config_base.cmake set(PLATFORM_PSA_ADAC_SECURE_DEBUG TRUE CACHE BOOL "Whether to use psa-adac secure debug.") set(PLATFORM_PSA_ADAC_SOURCE_PATH "DOWNLOAD" CACHE PATH "Path to source dir of psa-adac.") set(PLATFORM_PSA_ADAC_VERSION "819a254" CACHE STRING "The version of psa-adac to use.") 2) Build result (error) -- Populating libpsaadac -- Configuring done (0.0s) -- Generating done (0.0s) -- Build files have been written to: /home/jkpark/ADP620/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-subbuild [1/9] Creating directories for 'libpsaadac-populate' [1/9] Performing download step (git clone) for 'libpsaadac-populate' Cloning into 'libpsaadac-src'... HEAD is now at 819a254 ADAC: Check return value of psa_adac_generate_challenge [2/9] Performing update step for 'libpsaadac-populate' e*rror: pathspec '819a254;;' did not match any file(s) known to git * *CMake Error at .../libpsaadac-populate-gitupdate.cmake:188 (execute_process): * * execute_process failed command indexes: * * 1: "Child return code: 1" * 3) Generated ExternalProject invocation /cmake_build/rdv3r1/0/lib/ext/libpsaadac-subbuild/CMakeLists.txt include(ExternalProject) ExternalProject_Add(libpsaadac-populate "UPDATE_DISCONNECTED" "False" "GIT_REPOSITORY" "https://git.trustedfirmware.org/shared/psa-adac.git" "EXTERNALPROJECT_INTERNAL_ARGUMENT_SEPARATOR" "GIT_TAG" "819a254" "" "" SOURCE_DIR "/home/jkpark/ADP620/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-src" BINARY_DIR "/home/jkpark/ADP620/tf-m/cmake_build/rdv3r1/0/lib/ext/libpsaadac-build" CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND "" TEST_COMMAND "" USES_TERMINAL_DOWNLOAD YES USES_TERMINAL_UPDATE YES USES_TERMINAL_PATCH YES ) *Questions * *https://git.trustedfirmware.org/shared/psa-adac.git <https://git.trustedfirmware.org/shared/psa-adac.git> * *What is causing the tag-related error when using the repository at https://git.trustedfirmware.org/shared/psa-adac.git <https://git.trustedfirmware.org/shared/psa-adac.git> * ? Environment Path: /home/jkpark/ADP620/tf-m/cmake_build/rdv3r1/0/... Platform: RDV3R1 I would be grateful for any advice or pointers from anyone familiar with this. Thank you!

11 months, 1 week

2
3
0 0

Update: TF-M now uses Python packaging for modules and scripts

by Mudit Sharma

Hi all, TF-M has recently introduced Python packaging for its modules and scripts. If you’re building the latest TF-M mainline, you’ll need to install them by running the following command from the root of the TF-M repository (using a virtual environment is recommended): ``` pip install . ``` or ``` # `-e` installs modules and scripts in editable/development mode i.e. source edits are automatically reflected in your dev environment pip install -e . ``` NOTE: You'll have to re-run the above command every time a new module is added, module is renamed or a new dependency is added. The documentation [1] has been updated with more details. In addition, new guidelines are now available [2] for adding new scripts and modules. Thank you. Best regards, Mudit Sharma [1]: https://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.ht… [2]: https://trustedfirmware-m.readthedocs.io/en/latest/contributing/python_scri…

11 months, 2 weeks

1
0
0 0

Re: [CANCELLED] 28/08 TF-M Tech forum

by Antonio De Angelis

Hi, TF-M's tech forum of today is cancelled due to unforeseen circumstances. Talks that were scheduled for today are postponed. Will confirm in which one of the upcoming occurrences. Apologies for the short notice. Thanks, Antonio ________________________________ From: Trusted Firmware Public Meetings Sent: Friday, June 6, 2025 10:03:13 AM To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; Anton Komlev <Anton.Komlev(a)arm.com>; Don Harbin <don.harbin(a)linaro.org>; abdelmalek.omar1(a)gmail.com <abdelmalek.omar1(a)gmail.com>; Kevin Townsend (kevin.townsend(a)linaro.org) <kevin.townsend(a)linaro.org>; seth(a)nxmlabs.com <seth(a)nxmlabs.com>; leonardo.sandoval(a)linaro.org <leonardo.sandoval(a)linaro.org>; Joanna Farley <Joanna.Farley(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Tech forum When: Thursday, August 28, 2025 4:00 PM-5:00 PM. Where: https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… This email keeps the event up to date in your calendar. Set up inbox filters to hide this and similar calendar sync emails. Learn more about calendar sync emails and setting up filters<https://support.google.com/calendar?p=filter_invitations> This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward it to colleagues. Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> ===Zoom Info==== Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: TF-M Tech forum - US Time Zone Friendly Time: Oct 29, 2020 03:00 PM Greenwich Mean Time Every 4 weeks on Thu, until Mar 18, 2021, 6 occurrence(s) Oct 29, 2020 03:00 PM Nov 26, 2020 03:00 PM Dec 24, 2020 03:00 PM Jan 21, 2021 03:00 PM Feb 18, 2021 03:00 PM Mar 18, 2021 03:00 PM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmeeting%2Ft…> Join Zoom Meeting https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9557079…> Meeting ID: 955 7079 5742 Passcode: 177658 One tap mobile +12532158782,,95570795742# US (Tacoma) +13462487799,,95570795742# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 955 7079 5742 Find your local number: https://linaro-org.zoom.us/u/abx3I7IoRq<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2Fabx3I7I…> When Every 4 weeks from 8am to 9am on Thursday (Mountain Standard Time - Phoenix) Location https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… View map<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9557079…> Guests Don Harbin<mailto:don.harbin@linaro.org> - creator anton.komlev(a)arm.com<mailto:anton.komlev@arm.com> abdelmalek.omar1(a)gmail.com<mailto:abdelmalek.omar1@gmail.com> kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org> seth(a)nxmlabs.com<mailto:seth@nxmlabs.com> leonardo.sandoval(a)linaro.org<mailto:leonardo.sandoval@linaro.org> Joanna Farley<mailto:joanna.farley@arm.com> tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Invitation from Google Calendar<https://calendar.google.com/calendar/> You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>

11 months, 3 weeks

1
0
0 0

by Takekazu Tabata (Fujitsu)

Dear TF-M Team, I'm Takekazu Tabata, a director and architect from the Fujitsu processor team. We are currently developing FUJITSU-MONAKA, which supports the CCA feature. We have three questions regarding the TF-M documents and TF-M implementations. We would greatly appreciate it if you could provide answers. Question 1) In the TF-M document “RSE provisioning”, The CM provisioning Key is used to encrypt DM Provisioning Bundle. https://trustedfirmware-m.readthedocs.io/en/latest/platform/arm/rse/rse_pro… After the cold reset, the RSE will automatically transition to Device Manufacturer provisioning state “DM” as the LCM hardware state-machine reads the values of the cm_config_1 and cm_config_2 fields as non-zero. This state is designed to provision the DM provisioning key, the DM code-encryption key and the DM config. The procedure follows the same steps as the CM provisioning flow, with the exception that the bundle will now be encrypted and signed using the CM provisioning key and must be placed at the base of VM1. However, the purpose of the data provided in the DM is not described in this document. These data are not used in the source code of TF-M v2.2.0. DM provisioning is probably assumed to be done during device manufacturing, but could you explain the purpose in more detail? Also, What are the DM provisioning key, the DM code-encryption key and the DM config used for? Question 2) In the TF-M document “RSE integration guide”, attestation key(CPAK) is derived by GUK. https://trustedfirmware-m.readthedocs.io/en/latest/platform/arm/rse/rse_int…<https://trustedfirmware-m.readthedocs.io/en/latest/platform/arm/rse/rse_int…> The GUK is a key unique to a group of chips that have identical security properties, used to derive the attestation key. However, CPAK is derived from HUK in the source code of TF-M. GUK in the specification is a typo. https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git…<https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git…> /* This derives from HUK, there is a typo in the spec, not from GUK. * FixMe: this should be configurable per platform */ return setup_key_from_derivation(KMU_HW_SLOT_HUK, NULL, iak_seed_label, sizeof(iak_seed_label), NULL, 0, RSE_KMU_SLOT_CPAK_SEED, /* FixMe: The slot needs rename to IAK_SEED */ &aes_key0_export_config, NULL, false, boot_state_config); Which is right, GUK or HUK? If it‘s HUK (not Virtual HUK), is it no problem that multiple CPAKs are generated in Multi-socket systems? Question 3) In the CM/DM lifecycle state, is it no problem to create an original provisioning bundle to run chip or device verification programs in PE? Thank you for your time and assistance. Best regards, TABATA

1 year

2
6
0 0

Clarification on IRQ Preemption of Secure User Context by Non-Secure Interrupts

by Waqar Ali Tahir

Dear TF-M Community, I have a question regarding a specific use case involving interrupt handling and domain preemption in a TrustZone-enabled system using TF-M. In the scenario where the processor is executing within a Secure user context (e.g., during Secure Partition execution), is it possible for an interrupt assigned to the Non-Secure domain to pre-empt this Secure execution? * Does TF-M support such preemption by default? * If not supported out-of-the-box, what modifications or configuration changes would be required within TF-M to enable this behavior? Any guidance on how TF-M manages interrupt priority and security attribution in this context would be greatly appreciated. Best regards, Waqar Ali Waqar Ali Tahir (He / Him / His) Embedded SW Engineer Phone: +433124 299160 Email: <mailto:waqar.tahir@nxp.com> waqar.tahir(a)nxp.com NXP Semiconductors Austria GmbH & Co KG | Mikronweg 1, 8101 Gratkorn | Austria | Sitz: Gratkorn, Österreich | Firmenbuchgericht: Landesgericht für ZRS Graz | Firmenbuchnummer: FN 541474 k | VAT: ATU76231908 Unless otherwise recorded in a signed, written agreement, all sales transactions by NXP are exclusively subject to NXPs Terms and Conditions of Commercial Sale (NXP Terms) published at: <http://www.nxp.com/profile/terms/index.html> www.nxp.com/profile/terms/index.html. NXP explicitly rejects and disregards any terms and conditions of customer that add to, or differ from, NXPs Terms irrespective of when customer raises its terms. The information contained in this message is confidential. The message is intended solely for the addressee(s). If you are not the intended recipient, any use, dissemination, or reproduction is strictly prohibited and may be unlawful and you are asked to please contact the sender by return e-mail and destroy all copies of the original message.

1 year

2
1
0 0

Re: RSE booting with HardFault issue when TRAM enabled

by 김륜현

Hi Raef, I share the issue while applying shared patchset. Because a variable 'dma_channel_amount' is used after the DMA wipe DTCM,   it causes that dma_channel_amount have wrong data when waiting for DMA channel finish.     /* Configure all DMA channels to wipe the DTCM with the random value in parallel. */     for (int idx = 0; idx < dma_channel_amount; idx++) {         /* DMA channel configuration to wipe DTCM*/     }     /* Wait for all the DMA channels to finish */     for (int idx = 0; idx < dma_channel_amount; idx++) { // Error occurs at here         while ((*((volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x000)) & 0x1) != 0) {}     } So i have chosen a way that use defined value using #define like below.     /* Enable the TRAM */     *(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001;     /* Generate the TRAM erase random value */     tram_erase_value = *((volatile uint32_t *)(CC3XX_BASE_S + 0x124));     /* Configure all DMA channels to wipe the DTCM with the random value in parallel. */     for (int idx = 0; idx < DMA350_DMA0_CHANNEL_COUNT; idx++) {         /* LINKADDR must be cleared because the command linking is used in DMA H/W boot. */         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x078) = 0x00000000;                   *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x038) = tram_erase_value;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x02c) = 0x000F0044;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x018) =             DTCM_CPU0_BASE_S + (DTCM_SIZE / DMA350_DMA0_CHANNEL_COUNT * idx);         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x030) = 0x00010000;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x020) =             (DTCM_SIZE / sizeof(uint64_t) / DMA350_DMA0_CHANNEL_COUNT) << 16;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x024) = 0x00000000;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x00c) = 0x01200603;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x008) = 0x00000000;         *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x000) = 0x00000001;     }     /* Wait for all the DMA channels to finish */     for (int idx = 0; idx < DMA350_DMA0_CHANNEL_COUNT; idx++) {         while ((*((volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x100 * idx + 0x000)) & 0x1) != 0) {}     } Please refer to it. Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr> 날짜: 2025-07-28 22:06:49 제목: Re: [TF-M] Re: RSE booting with HardFault issue when TRAM enabled Ah thanks for the testing - I had indeed reused a variable after the TRAM init but before the zero. The following patchset should fix it, and remove the unneeded DMA ICS commands https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/41222/2 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/41224/1 Thanks, Raef ________________________________________ From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 28 July 2025 12:57 To: Raef Coles; tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Re: RSE booting with HardFault issue when TRAM enabled OK, Thank you for sharing the plan. About applying patch you gave,(https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838) Using variables immediately after TRAM enable can cause bus errors due to the same reason we discussing. /* Enable the TRAM */ *(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001; In actual, the access to variables in DTCM occur bus error after TRAM enabled. So i modified that it temporarily clear to 0 without using variable. /* Enable the TRAM */ *(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001; /* Erase the DTCM */ *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x038) = 0; // FILLVAL *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x02c) = 0x000F0044; // DESTRANSCFG *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x018) = DTCM_CPU0_BASE_S; // DESADDR *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x030) = 0x00010000; // XADDRINC *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x020) = (DTCM_SIZE / sizeof(uint64_t)) << 16; // XSIZE *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x00c) = 0x1200603; // CONFIG *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x008) = 0x00000000; // Disable All Interrupt *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000) = 0x00000001; // RUN_CMD while ((*((volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000)) & 0x1) != 0) {} But, it needs to find a fundamental solution. Please check it and i will share the solution if we find good idea. Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: 김륜현 <winxp4333@adtek.co.kr>,tf-m@lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> 날짜: 2025-07-28 19:28:00 제목: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Yeah you're right, the patch does add some duplication. In future we plan to remove the commands to generate the TRAM key, set the TRAM key, initialize the TRAM and erase the TRAM from the DMA ICS. This way it will always be handled in SW. The issue we have is that the TRAM setup requires retrieving random values from the TRNG, and whether that is possible in the DMA ICS depends on which HW TRNG is being used. With a single register read interface (which is what the ICS assumes) it works okay, but with (for example) the cryptocell TRNG it's not possible to read using the ICS since it requires a poll on a status register and it's not possible to encode that into a DMA command. To avoid having some TRNGs using the ICS and some using SW, we figured it was more sensible to perform the TRAM setup in SW in all cases. I believe that the new SW flow _should_ work if the DMA flow has already been run, but if there are any issues (likely with the KMU keyslot) then the simplest solution is to just remove the DMA commands. Raef ________________________________________ From: 김륜현 <winxp4333(a)adtek.co.kr> Sent: 28 July 2025 02:00 To: Raef Coles; tf-m(a)lists.trustedfirmware.org Subject: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hi Raef Thanks for your answer. I'm trying to apply your patch our base code, but some of issue occur. I will share the result when the patch is applied properly. Before that, i have a question. As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot. (platform/ext/target/arm/rse/common/bl1/scripts) I think that it seems to do duplicate operation as S/W about enabling TRAM. Regarding this, is there still no fixed method for enabling TRAM? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr> 날짜: 2025-07-24 21:00:22 제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hey RH Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing). We've just merged a patch upstream which: * Replaces the function calls with fixed register writes to avoid issues with uninitialized global data * Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838 Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated. Raef ________________________________________ From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 24 July 2025 05:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled. setup_tram_encryption()(a)startup_rse_bl1_1.c tram_enable_encryption(&tram_dev_s); if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below. tram_enable_encryption(&tram_dev_s); - if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { + if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random(). But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable? or is there anything to fix this problem? Best Regards RH Kim

1 year

1
0
0 0

Re: RSE booting with HardFault issue when TRAM enabled

by 김륜현

OK, Thank you for sharing the plan. About applying patch you gave,(https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838)… Using variables immediately after TRAM enable can cause bus errors due to the same reason we discussing. /* Enable the TRAM */ *(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001; In actual, the access to variables in DTCM occur bus error after TRAM enabled. So i modified that it temporarily clear to 0 without using variable.     /* Enable the TRAM */     *(volatile uint32_t *)(TRAM_BASE_S + 0x004) = 0x00000001;     /* Erase the DTCM */     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 +  0x038) = 0; // FILLVAL     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 +  0x02c) = 0x000F0044; // DESTRANSCFG     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 +  0x018) =  DTCM_CPU0_BASE_S; // DESADDR     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x030) = 0x00010000; // XADDRINC     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x020) = (DTCM_SIZE / sizeof(uint64_t)) << 16; // XSIZE     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x00c) = 0x1200603; // CONFIG     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x008) = 0x00000000; // Disable All Interrupt     *(volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000) = 0x00000001; // RUN_CMD          while ((*((volatile uint32_t *)(DMA_350_BASE_S + 0x1000 + 0x000)) & 0x1) != 0) {} But, it needs to find a fundamental solution. Please check it and i will share the solution if we find good idea. Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: 김륜현 <winxp4333@adtek.co.kr>,tf-m@lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> 날짜: 2025-07-28 19:28:00 제목: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Yeah you're right, the patch does add some duplication. In future we plan to remove the commands to generate the TRAM key, set the TRAM key, initialize the TRAM and erase the TRAM from the DMA ICS. This way it will always be handled in SW. The issue we have is that the TRAM setup requires retrieving random values from the TRNG, and whether that is possible in the DMA ICS depends on which HW TRNG is being used. With a single register read interface (which is what the ICS assumes) it works okay, but with (for example) the cryptocell TRNG it's not possible to read using the ICS since it requires a poll on a status register and it's not possible to encode that into a DMA command. To avoid having some TRNGs using the ICS and some using SW, we figured it was more sensible to perform the TRAM setup in SW in all cases. I believe that the new SW flow _should_ work if the DMA flow has already been run, but if there are any issues (likely with the KMU keyslot) then the simplest solution is to just remove the DMA commands. Raef ________________________________________ From: 김륜현 <winxp4333(a)adtek.co.kr> Sent: 28 July 2025 02:00 To: Raef Coles; tf-m(a)lists.trustedfirmware.org Subject: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hi Raef Thanks for your answer. I'm trying to apply your patch our base code, but some of issue occur. I will share the result when the patch is applied properly. Before that, i have a question. As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot. (platform/ext/target/arm/rse/common/bl1/scripts) I think that it seems to do duplicate operation as S/W about enabling TRAM. Regarding this, is there still no fixed method for enabling TRAM? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr> 날짜: 2025-07-24 21:00:22 제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hey RH Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing). We've just merged a patch upstream which: * Replaces the function calls with fixed register writes to avoid issues with uninitialized global data * Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838 Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated. Raef ________________________________________ From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 24 July 2025 05:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled. setup_tram_encryption()(a)startup_rse_bl1_1.c tram_enable_encryption(&tram_dev_s); if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below. tram_enable_encryption(&tram_dev_s); - if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { + if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random(). But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable? or is there anything to fix this problem? Best Regards RH Kim

1 year

2
1
0 0

Re: RSE booting with HardFault issue when TRAM enabled

by Raef Coles

Yeah you're right, the patch does add some duplication. In future we plan to remove the commands to generate the TRAM key, set the TRAM key, initialize the TRAM and erase the TRAM from the DMA ICS. This way it will always be handled in SW. The issue we have is that the TRAM setup requires retrieving random values from the TRNG, and whether that is possible in the DMA ICS depends on which HW TRNG is being used. With a single register read interface (which is what the ICS assumes) it works okay, but with (for example) the cryptocell TRNG it's not possible to read using the ICS since it requires a poll on a status register and it's not possible to encode that into a DMA command. To avoid having some TRNGs using the ICS and some using SW, we figured it was more sensible to perform the TRAM setup in SW in all cases. I believe that the new SW flow _should_ work if the DMA flow has already been run, but if there are any issues (likely with the KMU keyslot) then the simplest solution is to just remove the DMA commands. Raef ________________________________________ From: 김륜현 <winxp4333(a)adtek.co.kr> Sent: 28 July 2025 02:00 To: Raef Coles; tf-m(a)lists.trustedfirmware.org Subject: Re: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hi Raef Thanks for your answer. I'm trying to apply your patch our base code, but some of issue occur. I will share the result when the patch is applied properly. Before that, i have a question. As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot. (platform/ext/target/arm/rse/common/bl1/scripts) I think that it seems to do duplicate operation as S/W about enabling TRAM. Regarding this, is there still no fixed method for enabling TRAM? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>,김륜현 <winxp4333(a)adtek.co.kr> 날짜: 2025-07-24 21:00:22 제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hey RH Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing). We've just merged a patch upstream which: * Replaces the function calls with fixed register writes to avoid issues with uninitialized global data * Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838 Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated. Raef ________________________________________ From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 24 July 2025 05:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled. setup_tram_encryption()(a)startup_rse_bl1_1.c tram_enable_encryption(&tram_dev_s); if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below. tram_enable_encryption(&tram_dev_s); - if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { + if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random(). But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable? or is there anything to fix this problem? Best Regards RH Kim

1 year

1
0
0 0

Re: RSE booting with HardFault issue when TRAM enabled

by 김륜현

Hi Raef Thanks for your answer. I'm trying to apply your patch our base code, but some of issue occur.  I will share the result when the patch is applied properly. Before that, i have a question. As i know, DMA descriptor(Program6) enables TRAM on DMA H/W boot. (platform/ext/target/arm/rse/common/bl1/scripts) I think that it seems to do duplicate operation as S/W about enabling TRAM. Regarding this, is there still no fixed method for enabling TRAM? Best Regards RH Kim ----- 원본 메시지 ----- 보낸 사람: Raef Coles <Raef.Coles(a)arm.com> 받는 사람: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.xn--org>,-7104au55ev23e <winxp4333(a)adtek.co.kr> 날짜: 2025-07-24 21:00:22 제목: Re: [TF-M] RSE booting with HardFault issue when TRAM enabled Hey RH Apologies, this has been a known issue for a while (or rather, a series of known issues that we keep fixing). We've just merged a patch upstream which: * Replaces the function calls with fixed register writes to avoid issues with uninitialized global data * Performs DTCM initialization in all cases, avoiding relying on the DMA ICS or having to check the SP mode You can find it here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40838 Unfortunately we've only been able to test it on the FVP at the moment, which has limited ECC support. If you'd be able to test the patch and let me know if it fixes your issue, that would be appreciated. Raef ________________________________________ From: 김륜현 via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 24 July 2025 05:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] RSE booting with HardFault issue when TRAM enabled Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM OFF CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM ON CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled. setup_tram_encryption()(a)startup_rse_bl1_1.c tram_enable_encryption(&tram_dev_s); if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below. tram_enable_encryption(&tram_dev_s); - if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { + if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word)); for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) { ((uint32_t *)DTCM_BASE_S)[idx] = random_word; } } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random(). But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable? or is there anything to fix this problem? Best Regards RH Kim

1 year

1
0
0 0

RSE booting with HardFault issue when TRAM enabled

by 김륜현

Dear TF-M developers Hello, i'm developing and porting TF-M our platforms based on RDV3R1. To enable TRAM, i modified a cmake config file like below(platform/ext/target/arm/rse/common/config.cmake) - set(RSE_ENABLE_TRAM                     OFF       CACHE BOOL "Whether TRAM encryption is enabled") + set(RSE_ENABLE_TRAM                     ON       CACHE BOOL "Whether TRAM encryption is enabled") First of all, RSE core boots with Virgin CM  In this mode, Secure Provisioning is not enabled so that the DTCM don't be initialized even if TRAM is enabled.  setup_tram_encryption()(a)startup_rse_bl1_1.c     tram_enable_encryption(&tram_dev_s);     if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {         bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));         for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {             ((uint32_t *)DTCM_BASE_S)[idx] = random_word;         }     } Because DTCM doesn't be initialized, the next codes which use global variable in BL1_1 data section on DTCM cause hardfault. So, i applied the workaround by modifying condition like below.     tram_enable_encryption(&tram_dev_s); -    if (sp_enabled == LCM_TRUE && (lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) { +   if ((lcs == LCM_LCS_CM || lcs == LCM_LCS_DM)) {         bl1_trng_generate_random((uint8_t *)&random_word, sizeof(random_word));         for (idx = 0; idx < DTCM_SIZE / sizeof(uint32_t); idx++) {             ((uint32_t *)DTCM_BASE_S)[idx] = random_word;         }     } But the global variable in uninitialized DTCM are also used in bl1_trng_generate_random(). So, i tried to initialize DTCM as 0 without calling bl1_trng_generate_random().  But after that, setting SP_ENABLED for CM Provisioning causes warm reset, TRAM is disabled but DTCM doesn't be initialized. It causes same problem. I know that enabling TRAM is performed DMA descriptor without RSE_ENABLE_TRAM option, it may also cause the problem because of the phenomenon that TRAM is disabled but DTCM doesn't be initialized when warm reset. Should i modify let it use local variable?  or is there anything to fix this problem? Best Regards RH Kim

1 year

2
1
0 0

Re: Issue with integrity_checker_compute_value() and cache coherence on RDV3R1 with TF-M

by 박진국

Hi Raef Based on your advice, I made the modifications as below and confirmed that it works properly. Thank you for your help. JK Park enum integrity_checker_error_t integrity_checker_compute_value_bl2(struct integrity_checker_dev_t *dev, enum integrity_checker_mode_t mode, const uint32_t *data, size_t size, uint32_t *value, size_t value_size, size_t *value_len) { //volatile uint32_t __ALIGNED(INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) // temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; //jkpark volatile uint32_t __ALIGNED(32) temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; volatile uint32_t *value_ptr = value; struct _integrity_checker_reg_map_t* p_integrity_checker = (struct _integrity_checker_reg_map_t*)dev->cfg->base; enum integrity_checker_error_t err; uint32_t iccval = 0; err = check_mode_is_supported(dev, mode, true); if (err != INTEGRITY_CHECKER_ERROR_NONE) { return err; } if (value_size < mode_sizes[mode]) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL; } if (((uintptr_t)data % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT; } if ((size % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH; } init_integrity_checker(dev, &iccval); /* Set algorithm */ iccval |= (mode & 0b111) << 1; /* Set to compute mode */ iccval |= 1 << 4; /* Configure input data. Size is in words */ p_integrity_checker->icda = remap_addr(dev, (uintptr_t)data); p_integrity_checker->icdl = size / INTEGRITY_CHECKER_REQUIRED_ALIGNMENT; /* Set output address */ p_integrity_checker->iccva = remap_addr(dev, (uintptr_t)value_ptr); /* Start integrity checker */ iccval |= 1; p_integrity_checker->icc = iccval; /* Poll for any interrupts */ while(!p_integrity_checker->icis) {} /* Check for any unusual error interrupts */ if (p_integrity_checker->icis & (~0b11)) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED; } SCB_InvalidateDCache_by_Addr((void *)temp_val, 32); if (value_ptr != value) { for (int idx = 0; idx < mode_sizes[mode] / sizeof(uint32_t); idx++) { value[idx] = value_ptr[idx]; } } if (value_len != NULL) { *value_len = mode_sizes[mode]; } return INTEGRITY_CHECKER_ERROR_NONE; } enum integrity_checker_error_t integrity_checker_check_value_bl2(struct integrity_checker_dev_t *dev, enum integrity_checker_mode_t mode, const uint32_t *data, size_t size, const uint32_t *value, size_t value_size) { //volatile uint32_t __ALIGNED(INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) // temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; //jkpark volatile uint32_t __ALIGNED(32) temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; const volatile uint32_t *value_ptr = value; struct _integrity_checker_reg_map_t* p_integrity_checker = (struct _integrity_checker_reg_map_t*)dev->cfg->base; enum integrity_checker_error_t err; uint32_t iccval = 0; err = check_mode_is_supported(dev, mode, false); if (err != INTEGRITY_CHECKER_ERROR_NONE) { return err; } if (value_size < mode_sizes[mode]) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_BUFFER_TOO_SMALL); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_BUFFER_TOO_SMALL; } if (((uintptr_t)data % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_INVALID_ALIGNMENT); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_INVALID_ALIGNMENT; } if ((size % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_INVALID_LENGTH); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_INVALID_LENGTH; } //if (((uintptr_t)value % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0 // || (value_size % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { for (int idx = 0; idx < value_size / sizeof(uint32_t); idx++) { temp_val[idx] = value[idx]; } value_ptr = temp_val; //} SCB_CleanDCache_by_Addr((void *)temp_val, 32); init_integrity_checker(dev, &iccval); /* Set algorithm */ iccval |= (mode & 0b111) << 1; /* Configure input data. Size is in words */ p_integrity_checker->icda = remap_addr(dev, (uintptr_t)data); p_integrity_checker->icdl = size / INTEGRITY_CHECKER_REQUIRED_ALIGNMENT; /* Set compare address */ p_integrity_checker->iceva = remap_addr(dev, (uintptr_t)value_ptr); /* Start integrity checker */ iccval |= 1; p_integrity_checker->icc = iccval; /* Poll for any interrupts */ while(!p_integrity_checker->icis) {} /* Check for any unusual error interrupts */ if (p_integrity_checker->icis & (~0b11)) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_OPERATION_FAILED); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_OPERATION_FAILED; } else if (p_integrity_checker->icis & (0b10)) { /* Check for comparison failure */ NONFATAL_ERR(INTEGRITY_CHECKER_ERROR_CHECK_VALUE_COMPARISON_FAILED); return INTEGRITY_CHECKER_ERROR_CHECK_VALUE_COMPARISON_FAILED; } return INTEGRITY_CHECKER_ERROR_NONE; }

1 year

1
0
0 0

Security vulnerability notice - Fix unchecked TLV payload length

by Anton Komlev

Hello, This is a notification regarding a newly reported security vulnerability in Trusted Firmware-M (TF-M): TFMV-9: Fix unchecked TLV payload length by Bartek Piekarski from Product Security team, Arm Ltd. Please find the detailed security advisory attached. The fix for this issue has been merged into the latest main branch under the same identifier: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40872 We are currently preparing hotfix releases v2.1.3 and v2.2.1, which will include this fix along with other bug fixes reported up to the release date via the TF-M issue tracker: https://github.com/TrustedFirmware-M/trusted-firmware-m/issues?q=is%3Aissue Thanks, and best regards Anton Komlev

1 year

1
0
0 0

Issue with integrity_checker_compute_value() and cache coherence on RDV3R1 with TF-M

by 박진국

Hello, I am currently developing TF-M on the RDV3R1 S/W platform, and I would like to report a potential issue observed during runtime with the integrity_checker_compute_value() function in BL2. Problem Description: Inside the integrity_checker_compute_value() function, the iccva register is set to the address of either the value or temp_val variable, as shown in the example below. enum integrity_checker_error_t integrity_checker_compute_value(struct integrity_checker_dev_t *dev, enum integrity_checker_mode_t mode, const uint32_t *data, size_t size, uint32_t *value, size_t value_size, size_t *value_len) { volatile uint32_t __ALIGNED(INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; volatile uint32_t *value_ptr = value; struct _integrity_checker_reg_map_t* p_integrity_checker = (struct _integrity_checker_reg_map_t*)dev->cfg->base; enum integrity_checker_error_t err; uint32_t iccval = 0; err = check_mode_is_supported(dev, mode, true); if (err != INTEGRITY_CHECKER_ERROR_NONE) { return err; } if (value_size < mode_sizes[mode]) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL; } if (((uintptr_t)data % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT; } if ((size % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH; } if (((uintptr_t)value % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { value_ptr = temp_val; } init_integrity_checker(dev, &iccval); /* Set algorithm */ iccval |= (mode & 0b111) << 1; /* Set to compute mode */ iccval |= 1 << 4; /* Configure input data. Size is in words */ p_integrity_checker->icda = remap_addr(dev, (uintptr_t)data); p_integrity_checker->icdl = size / INTEGRITY_CHECKER_REQUIRED_ALIGNMENT; /* Set output address */ p_integrity_checker->iccva = remap_addr(dev, (uintptr_t)value_ptr); /* Start integrity checker */ iccval |= 1; p_integrity_checker->icc = iccval; /* Poll for any interrupts */ while(!p_integrity_checker->icis) {} /* Check for any unusual error interrupts */ if (p_integrity_checker->icis & (~0b11)) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED; } if (value_ptr != value) { for (int idx = 0; idx < mode_sizes[mode] / sizeof(uint32_t); idx++) { value[idx] = value_ptr[idx]; } } if (value_len != NULL) { *value_len = mode_sizes[mode]; } return INTEGRITY_CHECKER_ERROR_NONE; } static void init_integrity_checker(struct integrity_checker_dev_t *dev, uint32_t *iccval) { struct _integrity_checker_reg_map_t* p_integrity_checker = (struct _integrity_checker_reg_map_t*)dev->cfg->base; /* Set MatchTriggerDisable, as it is mandatory. */ *iccval |= 1 << 5; /* Set EncompvalOut so the integrity checker writes the value pointer in * compute mode. */ *iccval |= 1 << 6; *iccval |= (IC_APROT_SECURE_PRIVILEGED & 0b11) << 7; *iccval |= (IC_APROT_SECURE_PRIVILEGED & 0b11) << 9; /* Disable all alarms */ p_integrity_checker->icae = 0; /* Enable and clear all interrupts */ p_integrity_checker->icie = 0xFF; p_integrity_checker->icic = 0xFF; } The issue arises because the memory areas pointed to by value and temp_val are cacheable (e.g., located in the vm0 memory region, which is configured as cacheable). As a result, even though the integrity checker writes the output data to the physical address of value or temp_val, the CPU cache is not updated, and this leads to stale data being read later in software, resulting in runtime errors. Expected Behavior: Ideally, the memory region used for integrity checker output should either be: Non-cacheable, or Explicitly synchronized (e.g., cache invalidated or cleaned) after the integrity checker operation. Could you please confirm whether this is a known issue, and advise on the recommended way to handle integrity checker outputs with respect to cache settings? Thank you. JK Park

1 year, 1 month

2
1
0 0

TF-M BL2 compiling issue using RDINFRA

by 김태훈

Hello, I'm a RSE firmware developer for Arm Neoverse V3 core. I tried to build with argument MCUBOOT_ENC_IMAGES, MCUBOOT_ENCRYPT_RSA, and MCUBOOT_USE_PSA_CRYPTO for RSE PE encryption. In this process, I encountered an error during build TF-M using the repo for tag:RD-INFRA-2025.07.03. It seems that linking problem, and I found out that the error occurred while configuring BL2. However, that's all. Can anyone help me? Below log is in my terminal output.  p.s. If I reached wrong site, please forgive me and teach me a right one. cmake --build build --target bl2 [  0%] Built target manifest_tool [  0%] Built target bl2_scatter [ 10%] Built target bl2_cc3xx_psa_driver_api [ 31%] Built target bl2_cc3xx [ 68%] Built target platform_bl2 [ 78%] Built target bl2_crypto [ 94%] Built target bootutil [ 94%] Linking C executable ../bin/bl2.axf /home/gth1919/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: ext/mcuboot/bootutil/libbootutil.a(encrypted.o): in function `bootutil_rsa_oaep_decrypt': /TF_M/build/lib/ext/mcuboot-src/boot/bootutil/include/bootutil/crypto/rsa.h:107: undefined reference to `psa_asymmetric_decrypt' Memory region         Used Size  Region Size  %age Used            FLASH:       80356 B       126 KB     62.28%              RAM:       35360 B       896 KB      3.85% collect2: error: ld returned 1 exit status gmake[3]: *** [bl2/CMakeFiles/bl2.dir/build.make:222: bin/bl2.axf] Error 1 gmake[2]: *** [CMakeFiles/Makefile2:2661: bl2/CMakeFiles/bl2.dir/all] Error 2 gmake[1]: *** [CMakeFiles/Makefile2:2668: bl2/CMakeFiles/bl2.dir/rule] Error 2 gmake: *** [Makefile:520: bl2] Error 2 HP. Mail.  010-6768-7791  gth1919(a)adtek.co.kr Application Platform Group김태훈 연구원 (주)에이디테크놀로지 (16512) 경기도 수원시 영통구 광교중앙로248번길 7-8 Web. http://www.adtek.co.kr

1 year, 1 month

2
1
0 0

Proposal to deprecate Musca-S1 and BL5340_dvk_cpuapp platforms

by Anton Komlev

Hi everyone, We would like to propose the deprecation of the following two TF-M platforms: 1. Musca-S1 (Arm) Musca-S1 was one of the earliest platforms featuring an Armv8-M silicon implementation, providing a valuable real hardware target for initial development. However, with the availability of many modern hardware platforms, Musca-S1 is no longer essential and can be deprecated. 2. BL5340_dvk_cpuapp (Laird Connectivity) This platform was initially proposed for deprecation at the end of 2023. Support activity has been minimal, and it closely mirrors the already-supported nRF5340 platform from Nordic Semiconductor. Please share any comments or objections regarding this proposal. If no major concerns are raised by the end of June 2025, we plan to mark these platforms as deprecated and proceed with their removal from the codebase. Thank you, Anton

1 year, 1 month

1
1
0 0

Trusted Firmware Gerrit issues

by Matthew Dalzell

Hi All, We have recently undergone a migration of our Gerrit server and are seeing some issues. One such change appears to be that https://review.trustedfirmware.org/TF-M/trusted-firmware-m no longer resolves to https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m. So please use the latter link if that is what you wish to access. This is causing a large slow-down on the CI causing jobs to not be run. These issues are being actively worked on and we hope all will be back up and running normally soon. If you have any questions or related issues please feel free to respond to this chain. Thank you for your patience, Matt

1 year, 1 month

1
1
0 0

Iar Linker duplicate file

by Inhelder Nicolas

Hi When compiling with IAR bxarm 9.7.1 i get the following linker errors: cmake -S . -B cmake_build -DTFM_PLATFORM=arm/mps2/an521 -DTFM_TOOLCHAIN_FILE=toolchain_IARARM.cmake cmake --build cmake_build -- install [25/31] Linking C executable bin/tfm_s.axf Warning[Li065]: duplicate file: "/home/ubuntu/import/source/trusted-firmware-m/ cmake_build/platform/libplatform_s.a" Warning[Li065]: duplicate file: "/home/ubuntu/import/source/trusted-firmware-m/ cmake_build/secure_fw/partitions/lib/runtime/libtfm_sprt.a" Warning[Li065]: duplicate file: "/home/ubuntu/import/source/trusted-firmware-m/ cmake_build/secure_fw/spm/libtfm_spm.a" In the build.ninja file you can see that all those libraries are includes twice. LINK_LIBRARIES = platform/libplatform_s.a secure_fw/partitions/lib/runtime/libtfm_sprt.a secure_fw/spm/libtfm_spm.a secure_fw/partitions/internal_trusted_storage/libtfm_psa_rot_partition_its.a secure_fw/partitions/platform/libtfm_psa_rot_partition_platform.a platform/libplatform_s.a secure_fw/partitions/lib/runtime/libtfm_sprt.a secure_fw/spm/libtfm_spm.a secure_fw/partitions/internal_trusted_storage/libtfm_psa_rot_partition_its.a secure_fw/partitions/platform/libtfm_psa_rot_partition_platform.a Is there a reason this is not resolved or this just the way Cmake works? Is there an easy way to resolve this on the platform level? I used the an521 as a template to create my platform. In my platform this list grows with every feature I activate: Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/platform/libplatform_s.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/lib/runtime/libtfm_sprt.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/spm/libtfm_spm.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/platform/libplatform_crypto_keys.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/crypto/mbedcrypto/library/libmbedcrypto.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/crypto/libtfm_psa_rot_partition_crypto.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/internal_trusted_storage/libtfm_psa_rot_partit ion_its.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/platform/libtfm_psa_rot_partition_platform.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/firmware_update/libtfm_psa_rot_partition_fwu.a " Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/lib/runtime/libtfm_sp_log.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/platform/libplatform_s.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/lib/runtime/libtfm_sprt.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/spm/libtfm_spm.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/platform/libplatform_crypto_keys.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/crypto/mbedcrypto/library/libmbedcrypto.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/crypto/libtfm_psa_rot_partition_crypto.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/internal_trusted_storage/libtfm_psa_rot_partit ion_its.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/platform/libtfm_psa_rot_partition_platform.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/firmware_update/libtfm_psa_rot_partition_fwu.a " Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/lib/runtime/libtfm_sp_log.a" If possible, I want to build without warnings. Thanks for your help Kind regards, Nico

1 year, 1 month

3
2
0 0

Constrains of key ownership in TF-M

by Norrathep Rattanavipanon

Hello, I just recently found out that there's a concept of key ownership in TF-M (e.g., if a new secure partition creates a key and returns the key handle to NSPE, NSPE can't export it even if the key is config-ed to be exportable -- the key can only be used by the owner). My question is: is this design based on PSA or specific to just TF-M implementation? Thank you in advance, -- Oak Norrathep -- ศูนย์กลางการศึกษานานาชาติ มุ่งสู่ความเป็นเลิศทางวิชาการของอาเซียน International education hub towards ASEAN’s academic excellence

1 year, 1 month

2
2
0 0

Question about build error in TF-M release/2.2.x

by Zhang, Hao

Hi TF-M community, When I am trying to build TF-M regression test for 2.2.x release, I sets the tf-m-tests repo version to recommended TF-Mv2.1.2-RC2. The tf-m-tests tests_reg/spe/CMakeLists.txt has following line: install(FILES ${CONFIG_TFM_SOURCE_PATH}/lib/ext/qcbor/q_useful_buf.h DESTINATION ${CMAKE_BINARY_DIR}/api_ns/qcbor/inc) However, release 2.2.x https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git… has removed q_useful_buf.h. Therefore, causing a build error. Is there anything I am missing. Any help would be appreciated. Best regards, Hao

1 year, 1 month

2
3
0 0

Build failure of release/2.1.x

by Zhang, Hao

Dear whoever that may concern, I am trying to build TF-M with release/2.1.x. The first error I see when cloning mbedcrypto is Cloning into 'mbedcrypto-src'... remote: Enumerating objects: 31188, done. remote: Counting objects: 100% (31188/31188), done. remote: Compressing objects: 100% (15898/15898), done. remote: Total 31188 (delta 24658), reused 20224 (delta 15043), pack-reused 0 (from 0) Receiving objects: 100% (31188/31188), 35.81 MiB | 4.89 MiB/s, done. Resolving deltas: 100% (24658/24658), done. fatal: invalid reference: f985bee CMake Error at mbedcrypto-subbuild/mbedcrypto-populate-prefix/tmp/mbedcrypto-populate-gitclone.cmake:40 (message): Failed to checkout tag: 'f985bee' I therefore change the GIT_SHALLOW to FALSE, and it builds. However, another build error come up when applying patches for mbedcrypto. Checking patch library/psa_crypto.c... Checking patch library/psa_crypto_driver_wrappers.h... error: library/psa_crypto_driver_wrappers.h: No such file or directory Checking patch library/psa_crypto_driver_wrappers_no_static.c... error: library/psa_crypto_driver_wrappers_no_static.c: No such file or directory I did checkout commit f985bee and find in fact there is no psa_crypto_driver_wrappers.h. Is it possible that the commit hash is incorrect? Best regards, Hao

1 year, 2 months

2
1
0 0

Synced invitation: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday (MST) (tf-m@lists.trustedfirmware.org)

by Don Harbin

This email keeps the event up to date in your calendar. TF-M Tech forum Every 4 weeks from 8am to 9am on Thursday Mountain Standard Time - Phoenix Location https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9557079… This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==… Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 18, 2021, 6 occurrence(s)        Oct 29, 2020 03:00 PM        Nov 26, 2020 03:00 PM        Dec 24, 2020 03:00 PM        Jan 21, 2021 03:00 PM        Feb 18, 2021 03:00 PM        Mar 18, 2021 03:00 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742# US (Tacoma)+13462487799,,95570795742# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number: https://linaro-org.zoom.us/u/abx3I7IoRq Guests Don Harbin - creator anton.komlev(a)arm.com abdelmalek.omar1(a)gmail.com kevin.townsend(a)linaro.org seth(a)nxmlabs.com leonardo.sandoval(a)linaro.org Joanna Farley tf-m(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 2 months

1
0
0 0

Synced invitation: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday from Thu Aug 31, 2023 to Wed Jun 4 (MST) (tf-m@lists.trustedfirmware.org)

by Don Harbin

This email keeps the event up to date in your calendar. TF-M Tech forum Every 4 weeks from 8am to 9am on Thursday from Thursday Aug 31, 2023 to Wednesday Jun 4 Mountain Standard Time - Phoenix Location https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9557079… This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==… Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 18, 2021, 6 occurrence(s)        Oct 29, 2020 03:00 PM        Nov 26, 2020 03:00 PM        Dec 24, 2020 03:00 PM        Jan 21, 2021 03:00 PM        Feb 18, 2021 03:00 PM        Mar 18, 2021 03:00 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742# US (Tacoma)+13462487799,,95570795742# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number: https://linaro-org.zoom.us/u/abx3I7IoRq Guests Don Harbin - creator anton.komlev(a)arm.com abdelmalek.omar1(a)gmail.com kevin.townsend(a)linaro.org seth(a)nxmlabs.com leonardo.sandoval(a)linaro.org Joanna Farley tf-m(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 year, 2 months

1
0
0 0

Broken link in TFO/TF-M entry page

by Etienne CARRIERE

Hello, I've seen that the "CONTRIBUTE/SUBMIT CODE<https://tf-m-user-guide.trustedfirmware.org/contributing/contributing_proce…>" link in https://www.trustedfirmware.org/projects/tf-m/ is broken. It links to deprecated https://tf-m-user-guide.trustedfirmware.org/contributing/contributing_proce… whereas I think it should link to https://trustedfirmware-m.readthedocs.io/en/latest/contributing/contributin…. Regards, Etienne Carriere

1 year, 2 months

2
1
0 0

Order of starting Secure Partitions

by Florek, Bartlomiej

Hello, I'm trying to fit a new Secure Partition into Trusted Firmware - M environment. The current working environment consists of Zephyr RTOS 3.7 + TF-M 2.1.0 running under QEMU on MPS2 AN521 platform. General skeleton is in place - manifest with dependencies on TFM_CRYPTO, interface, IPC and handling communication. However, I have problems with using the PSA Crypto from the aforementioned new Service. I need a hash function, so I thought I'd use PSA Crypto API. The problem is that either the hash function or the initialization function (psa_crypto_init) is returning error (PSA_ERROR_INSUFFICIENT_MEMORY). I discovered that logs show PSA Crypto partition is loading after mine. This problem occurs in the entry_point function. Is it possible to change the order of partitions loading or is there different mechanism advised to synchronize partition loading? Thank you in advance for your suggestions. Best regards, Bartlomiej

1 year, 2 months

4
8
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M