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