- TF-M - lists.trustedfirmware.org

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

4 months, 3 weeks

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>

4 months, 3 weeks

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

4 months, 3 weeks

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

4 months, 3 weeks

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>

4 months, 3 weeks

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>

4 months, 4 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

5 months

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>

5 months

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

5 months

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>

5 months, 1 week

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*

5 months, 2 weeks

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

5 months, 2 weeks

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>

5 months, 3 weeks

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

5 months, 3 weeks

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

5 months, 3 weeks

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.

6 months, 2 weeks

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

6 months, 2 weeks

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

6 months, 2 weeks

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

6 months, 3 weeks

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

6 months, 3 weeks

2
1
0 0

Test email-3 from PN

by Prasanth Nair

Test email-3 from PN

6 months, 3 weeks

1
0
0 0

Another Test from PN

by Prasanth Nair

Another Test from PN

6 months, 3 weeks

1
0
0 0

TF-M test message from PN

by Prasanth Nair

TF-M test message from PN

6 months, 3 weeks

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

6 months, 3 weeks

1
0
0 0

test message

by Anton Komlev

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

6 months, 3 weeks

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M