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