- TF-M - lists.trustedfirmware.org

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>

1 day, 16 hours

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

4 days, 13 hours

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

4 days, 13 hours

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

5 days, 13 hours

6
17
0 0

Technical Forum call - July 21

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 21, 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Link to the forum: https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 weeks, 6 days

12
97
0 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.

3 weeks, 6 days

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

3 weeks, 6 days

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

4 weeks, 1 day

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

1 month

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

1 month

2
1
0 0

Test email-3 from PN

by Prasanth Nair

Test email-3 from PN

1 month

1
0
0 0

Another Test from PN

by Prasanth Nair

Another Test from PN

1 month

1
0
0 0

TF-M test message from PN

by Prasanth Nair

TF-M test message from PN

1 month

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

1 month

1
0
0 0

test message

by Anton Komlev

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

1 month

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>

1 month

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

1 month

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

1 month

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

1 month, 1 week

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

1 month, 1 week

2
21
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

1 month, 2 weeks

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

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

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

1 month, 3 weeks

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

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

2 months

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.

2 months

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

2 months, 1 week

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

2 months, 1 week

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

2 months, 1 week

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.

2 months, 1 week

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.

2 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

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

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

2 months, 4 weeks

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.

3 months, 1 week

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

3 months, 1 week

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

3 months, 2 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.

4 months

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

4 months

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

4 months

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!

4 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…

4 months, 1 week

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>

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

5 months

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.

5 months, 1 week

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

5 months, 2 weeks

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

5 months, 2 weeks

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

5 months, 2 weeks

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

5 months, 2 weeks

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

5 months, 3 weeks

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; }

5 months, 3 weeks

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

5 months, 3 weeks

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

6 months

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

6 months

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

6 months, 1 week

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

6 months, 2 weeks

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

6 months, 2 weeks

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

6 months, 2 weeks

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

6 months, 3 weeks

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

7 months, 1 week

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

7 months, 1 week

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

7 months, 1 week

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

7 months, 1 week

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

7 months, 2 weeks

4
8
0 0

Planned outages

by Matthew Dalzell

Hi all, There are some planned outages for Friday morning (30th May UK around 10AM BST) to our CI. This will affect the review process for a short period of time, expected to be less than one hour, but may cause some disruption over the weekend too. I will be sure to send out another message once things have settled and should be back to normal. Thank you for your patience and apologies in advance for any issues which may arise, Matt

7 months, 2 weeks

1
2
0 0

Issue building docs

by Bohdan.Hunko＠infineon.com

Hi all, I am trying to build docs with following commands: cmake -S docs -B ./build_docs cmake --build build_docs/ -- tfm_docs_userguide_pdf But I get following error resolving references... failed Warning, treated as error: RSVG converter command 'rsvg-convert' cannot be run. Check the rsvg_converter_bin setting When I remove -W (warnings are errors) option from COMMAND "${SPHINX_EXECUTABLE}" -W -b html -j 1 -c ${SPHINXCFG_CONFIG_PATH} ${SPHINXCFG_SOURCE_PATH} "${SPHINXCFG_OUTPUT_PATH}/html" In docs/CMakeLists.txt then docs builds fine. Is this -W option intentional? Should this issue be fixed or -W removed? 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>

7 months, 2 weeks

2
2
0 0

PSA_IOT_PROFILE_1 attestation Certification Reference

by Quach, Brian

Hi, Per https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-07 (which is latest spec I can find for profile 1 token): The Certification Reference claim is used to link the class of chip and PSA RoT of the attesting device to an associated entry in the PSA Certification database. It MUST be represented as a thirteen-digit [EAN-13<https://www.gs1.org/standards/barcodes/ean-upc>].¶<https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-07#se…> Linking to the PSA Certification entry can still be achieved if this claim is not present in the token by making an association at a Verifier between the reference value and other token claim values - for example, the Implementation ID.¶<https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-07#se…> psa-certification-reference-type = text .regexp "[0-9]{13}" psa-certification-reference = ( ? psa-certification-reference-key => psa-certification-reference-type ) But in the tf-m-tools repo: iat-verifier\iatverifier\psa_iot_profile1_token_claims.py it checks for PSA 2.0 profile HW version which is EAN-13 + 5. class HardwareVersionClaim(AttestationClaim): """Class representing a PSA Attestation Token Hardware version claim""" def verify(self, token_item): self._check_type('HARDWARE_VERSION', token_item.value, str) value_len = len(token_item.value) expected_len = 19 # 'EAN13-Version' 13 + 1 + 5. e.g.:0604565272829-10010 if len(token_item.value) != expected_len: msg = 'Invalid HARDWARE_VERSION length; must be {} characters, found {} characters' self.verifier.error(msg.format(expected_len, value_len)) for idx, character in enumerate(token_item.value): if character not in string.digits: if idx != 13 or character not in '-': msg = 'Invalid character {} at position {}' self.verifier.error(msg.format(character, idx+1)) It seems like this was changed 3yrs ago: SHA-1: 8ac8d17d15353c7f7933ae8065646946ae47f993 * Fix HW Version claim expected length www.psacertified.org issuing HW versions of format '[0-9]{13}-[0-9]{5}'. It is called 'certification reference': https://www.psacertified.org/certified-products/ Signed-off-by: Tamas Ban <tamas.ban(a)arm.com> Change-Id: I0417e1ce76896f1128864676f29a4314b3fd1fb8 When I run "check_iat" script, I get these errors: ./scripts/check_iat -k public_key.pem -K -p -t PSA-IoT-Profile1-token cc27xx.cbor ERROR:iat-verifiers:Invalid HARDWARE_VERSION length; must be 19 characters, found 13 characters ERROR:iat-verifiers:Invalid character i at position 1 ERROR:iat-verifiers:Invalid character r at position 2 ERROR:iat-verifiers:Invalid character m at position 3 ERROR:iat-verifiers:Invalid character w at position 4 ERROR:iat-verifiers:Invalid character a at position 5 ERROR:iat-verifiers:Invalid character r at position 6 ERROR:iat-verifiers:Invalid character e at position 7 ERROR:iat-verifiers:Invalid character . at position 8 ERROR:iat-verifiers:Invalid character o at position 9 ERROR:iat-verifiers:Invalid character r at position 10 ERROR:iat-verifiers:Invalid character g at position 11 ERROR:iat-verifiers:Invalid character at position 12 ERROR:iat-verifiers:Invalid character at position 13 Is the verifier tool incorrect or should I be following "EAN13-Version' 13 + 1 + 5" even for profile 1 token? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

7 months, 3 weeks

3
3
0 0

Internal Trusted Storage

by Michael Khoyilar

Hi team, Can you help me with this statement that "Currently, the TF-M Secure Storage service implements PSA Protected Storage version 1.0-beta2. There is not yet an implementation of PSA Internal Trusted Storage in TF-M." Our SoC does NOT have internal flash, but we have OTP where we keep the confidential data. Can you help how to handle this ITS situation. I wonder if PSA level-2 certification requires ITS? Thanks BR Michael

7 months, 4 weeks

4
5
0 0

Re: [EXTERNAL] Re: Attestation calls to PSA Crypto

by Quach, Brian

Hi Antonio, I figured it out. I wasn’t including secure_fw/partitions/crypto/tfm_mbedcrypto_include.h properly so attestation was linking directly to the PSA Crypto function implementation instead of the client interface. I’m surprised it did not complain about a symbol collision without having the mbedcrypto__ prefix. The PSA crypto API implementation source files were “PRIVATE” so I’m not sure how attestation was able to link to them at all. Regards, Brian From: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> Sent: Thursday, May 8, 2025 9:42 AM To: Quach, Brian <brian(a)ti.com>; Mudit Sharma <Mudit.Sharma(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [EXTERNAL] Re: [TF-M] Attestation calls to PSA Crypto Hi Brian, we can't reproduce exactly that mixture easily but I don't think that should affect how the partition code gets linked to the interface code. Regardless of the type of partition (SFN/IPC) the linking of the interfaces should remain ZjQcmQRYFpfptBannerStart This message was sent from outside of Texas Instruments. Do not click links or open attachments unless you recognize the source of this email and know the content is safe. Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!tvdkk1ajei0aJagkHNPjPb…> ‌ ZjQcmQRYFpfptBannerEnd Hi Brian, we can't reproduce exactly that mixture easily but I don't think that should affect how the partition code gets linked to the interface code. Regardless of the type of partition (SFN/IPC) the linking of the interfaces should remain the same, i.e. your setup should not be able to link at all directly with the crypto library that provides the PSA Crypto APIs. Thanks, Antonio ________________________________ From: Quach, Brian Sent: Thursday, May 08, 2025 15:29 To: Mudit Sharma; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Antonio De Angelis Subject: RE: [EXTERNAL] Re: [TF-M] Attestation calls to PSA Crypto Hi Mudit, Thanks for checking. Is the build you tested using the same mix of SFN and IPC as I was? Regards, Brian From: Mudit Sharma <mudit.sharma(a)arm.com<mailto:mudit.sharma@arm.com>> Sent: Thursday, May 8, 2025 5:21 AM To: Quach, Brian <brian(a)ti.com<mailto:brian@ti.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com> Subject: [EXTERNAL] Re: [TF-M] Attestation calls to PSA Crypto Hi Brian, We built secure world TF-M test for AN521 platform: ``` cmake -S spe -B build_spe -DTFM_PLATFORM=arm/mps2/an521 \ -DCONFIG_TFM_SOURCE_PATH="$TFM_SOURCE_DIR" \ -DCMAKE_BUILD_TYPE=Debug \ -DTEST_S=ON -DTEST_NS=OFF ``` We ran this test ZjQcmQRYFpfptBannerStart This message was sent from outside of Texas Instruments. Do not click links or open attachments unless you recognize the source of this email and know the content is safe. Report Suspicious <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!uXdq_RaPN01xCsXEHfkD30…> ‌ ZjQcmQRYFpfptBannerEnd Hi Brian, We built secure world TF-M test for AN521 platform: ``` cmake -S spe -B build_spe -DTFM_PLATFORM=arm/mps2/an521 \ -DCONFIG_TFM_SOURCE_PATH="$TFM_SOURCE_DIR" \ -DCMAKE_BUILD_TYPE=Debug \ -DTEST_S=ON -DTEST_NS=OFF ``` We ran this test on a FVP model and stepped through `tfm_attest_test_1001`. Please find attached a screenshot of the call stack. Function in `attest_core` (in the Attestation partition) invokes function in the `tfm_crypto_api`. This request is routed by the Secure Partition Manager (SPM) into the Crypto partition via `psa_call()`. On 5/6/25 00:33, Quach, Brian wrote: > > Is my configuration valid? How should it work? > Any time you call a function across partitions, regardless of isolation level, the SPM forwards it to the target partition using `psa_call()` > Best regards, Mudit Sharma

8 months, 1 week

1
0
0 0

Attestation calls to PSA Crypto

by Quach, Brian

Hi, Assuming Isolation Level 1 and IPC backend, I'm using Attestation partition with SFN model with stateless handle and a custom Crypto partition using IPC model with stateless handle. My custom Crypto partition includes a PSA crypto wrapper which defines all the PSA Crypto APIs to use HW crypto. We used IPC since we want to be able to support isolation level 2-3 in the future. When the Attestation partition make calls to PSA Crypto (psa_hash_setup for example), should it use a psa_call() to the Crypto Partition? That is what I had expected since the crypto partition is IPC model but I'm seeing it call the PSA crypto code directly. Also, it appears to provide client side psa_hash_operation_t directly to the psa_hash_setup which is expecting the full operation struct. Is my configuration valid? How should it work? [ 52%] Building C object secure_fw/partitions/partitions/_1/crypto_sp/CMakeFiles/ti_tfm_psa_rot_partition_crypto.dir/home/brian/gits/secure_drivers/source/third_party/psa_crypto/psa_crypto_wrapper.o [ 53%] Building C object secure_fw/partitions/partitions/_1/crypto_sp/CMakeFiles/ti_tfm_psa_rot_partition_crypto.dir/__/__/__/__/__/generated/secure_fw/partitions/ti_crypto/auto_generated/intermedia_crypto_sp.o [ 53%] Building C object secure_fw/partitions/partitions/_1/crypto_sp/CMakeFiles/ti_tfm_psa_rot_partition_crypto.dir/home/brian/gits/spe/source/third_party/tfm/platform/ext/common/syscalls_stub.o [ 54%] Linking C static library libti_tfm_psa_rot_partition_crypto.a [ 54%] Built target ti_tfm_psa_rot_partition_crypto [ 54%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest.o [ 55%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest_req_mngr.o [ 55%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_core.o [ 56%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_boot_data.o [ 56%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_asymmetric_key.o [ 57%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_token_encode.o [ 57%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/intermedia_tfm_initial_attestation.o [ 58%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_sign.o [ 58%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_verify.o [ 59%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_util.o [ 59%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_parameters.o [ 60%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o [ 60%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/platform/ext/common/syscalls_stub.o [ 61%] Linking C static library libtfm_psa_rot_partition_attestation.a [ 61%] Built target tfm_psa_rot_partition_attestation [ 61%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/platform/ext/common/syscalls_stub.o [ 62%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/crt_memcmp.o [ 62%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/crt_memmove.o [ 63%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/crt_strnlen.o [ 63%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/service_api.o [ 64%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/shared/crt_memcpy.o [ 64%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/shared/crt_memset.o [ 65%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/sprt_partition_metadata_indicator.o [ 65%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/sfn_common_thread.o [ 66%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/psa_api_ipc.o [ 66%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/spm/core/psa_interface_thread_fn_call.o [ 67%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_attest_api.o [ 67%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_psa_call.o [ 68%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_crypto_api.o [ 68%] Linking C static library libtfm_sprt.a Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

8 months, 1 week

3
4
0 0

TF-M v2.2.0 and TF-M v2.1.2 Releases Announcement

by Anton Komlev

Hi everyone, We're excited to announce the release of TF-M v2.2.0! Major Highlights: * LLVM build support for MPS2/3/4 and RSE platforms. * Mbed TLS upgraded to version 3.6.3. * Now compliant with PSA Architecture Compliance Kit tests v1.6. * Initial hybrid platform support: * Enables on-core and off-core clients (A-profile + M-profile or multiple M-profile). * Uses HYBRID_PLAT_SCHED_TYPE=NSPE (aka Solution 2). * Note: This feature is under active development and testing. * New platforms support * Initial support for building nRF54L15 * Initial support for building stm32wba65i-dk For full details, please refer to the release notes<https://trustedfirmware-m.readthedocs.io/en/tf-mv2.2.0/releases/2.2.0.html>. TF-M v2.1.2 (LTS) Release We've also released TF-M v2.1.2 on the LTS branch, which includes critical bug fixes, such as: * Fixed issue where Protected Storage content could be lost under full storage conditions followed by device resets. * Correctly mark NSPE images in the wrapper. * Various SPM fixes: * Removed specific section for psa_interface_thread_fn_call. * Added missing fih_rc return value checks in interrupts. * Resolved issues with IOVEC unmapping. * Proper handling of refused psa_connect calls. * Fixed invalid connection retention after psa_close. * Resolved issues with reverse-handle usage. * * New platform support: * MAX32657 port now available. A huge thank you to everyone who contributed, reviewed, and supported this release! The v2.2.0 changes will be ported to the main branch shortly. Stay tuned! Anton and TF-M team

9 months

1
0
0 0

FW: Weird behavior of Clang linker

by Bohdan.Hunko＠infineon.com

Hi Just forwarding older private discussion to mailing list to make it publicly available. 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> From: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> Sent: Thursday, December 14, 2023 15:57 To: Mazurak Roman (CSS ICW SW FW 3) <Roman.Mazurak(a)infineon.com>; Anton Komlev <Anton.Komlev(a)arm.com>; Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com> Subject: Re: Weird behavior of Clang linker Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Roman, I tried to look in the ELF spec that I could find by googling, but what I can find online doesn't mention the topic of alignment requirements at all other than a brief mention of how the base address and align requirements must be coherent. How the requirement on alignment propagates from sections to execution regions to load regions is still something that I am trying to understand as I can't find an exhaustive description. The info I shared below stem from a personal conversation that I had with the compiler team internally here in Arm, I have now asked for a reference, will revert back to you in case I get one. [cid:0aef50f0-9105-480f-8090-06cfaa06b8d3] Only explicit mention of alignment that I could find is in the armlink manual in section 3.3.3. [cid:ef5c45ef-7d67-433c-9aba-b8fd7cf0d1c0] The suggestion from the compiler team are as I mentioned: 1. just disable the strict checks on alignment (i.e. the linker will be then allowed to add padding as required to meet the constraint imposed by the base address of the load region and the ALIGN attributes, by suppressing the diagnostic or using --legacyalign (on a side note, I believe this is the default behaviour on GCC linker for example) 2. rewrite the scatter file to have all the input sections without alignment requirements in the output section where the vector reside, and then have another output section just after the first output section (i.e. with base address +0) to put all the other input sections with increased alignment. As a side note, the suggestion is to also align base addresses of sections using AlignExpr(+0, 4096) (for example, to align to 0x1000) rather than forcing ALIGN attributes. Note that this shouldn't be too complex to attain point 2 but it is something that at the moment we can't work on, but happily merge it in if you're willing to provide a patch for it. Your suggestion of having multiple output section is as well doable, but probably enough to have two of them. Will get back to you in case I get some more reference about how the alignment requirements in ELF propagate from input section to output sections just to confirm on the spec itself. Hope this helps, please let me know if any questions! Thanks, Antonio ________________________________ From: Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com> <Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>> Sent: Thursday, December 14, 2023 13:37 To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com> <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>> Subject: RE: Weird behavior of Clang linker Hi Antonio, We have a use case when output section has following list of input sections: * Vectors with alignment by 0x400. * Partitions sections with alignment by 0x1000. As result output section alignment is 0x1000 and address is incorrect. So, probably it’s necessary to create a separate output section for each input section. Can you share a link to ELF specification with requirements for output section alignment? Best regards, Roman. From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, December 13, 2023 18:56 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>> Subject: [TF-M] Re: Weird behavior of Clang linker Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Bohdan, For reference, this is due to armlink being strict on following the ELF specification for which the region alignment is derived as the maximum alignment of the input sections. You can relax this requirement with armlink by either using the --legacyalign option (although it's being deprecated) or suppressing the diagnostic --diag_suppress=6244. In the future, we could try to reorganize the scatter file for the armclang toolchain to avoid using directly ALIGN attributes and align the base address of the execution regions using AlignExpr() instead, but even with this strategy, any alignment requirement which stems from using .aligned directive in assembly or attribute __ ((aligned)) attributes will influence the input sections alignment, hence it will require a deeper restructuring of the scatter file, possibly moving sections with increased alignment in a separate load region just after LR_CODE which must have a base address that forces a natural alignment. Hope this helps. Thanks, Antonio ________________________________ From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Monday, December 11, 2023 13:39 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Re: Weird behavior of Clang linker Hi Anton, Here is the version I am using: $ armclang --version Product: Arm Development Studio Gold Edition 2020.1 Component: Arm Compiler for Embedded 6.19 Tool: armclang [5e73cb00] Target: unspecified-arm-none-unspecified 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> From: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Sent: Monday, December 11, 2023 15:34 To: Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: Weird behavior of Clang linker Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Bohdan, What is Clang version you are using? Thanks, Anton From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Monday, December 11, 2023 12:58 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Weird behavior of Clang linker Hi all, Our platform uses 4KBs alignment in linker files (as this is the requirement of our protection HW). For this reasons I have introduced tfm_s_linker_alignments.h. Everything works fine with GCC but we have a problem with Clang. The problem is that Clang requires LR_CODE to have same alignment as other sections inside of it. Following are the steps to reproduce the issue: 1. Set TFM_LINKER_DEFAULT_ALIGNMENT to 0x1000 in tfm_s_linker_alignments.h 2. Build AN521 with following command line cmake -S . -B build_an521 -DTFM_PLATFORM=arm/mps2/an521 -DTFM_TOOLCHAIN_FILE=./toolchain_ARMCLANG.cmake Expected result: Everything works fine Actual result: Error: L6244E: Load region LR_CODE address (0x10080400) not aligned on a 4096 byte boundary. This error is weird because there is no explicit alignment assigned to LR_CODE region. Would appreciate a help on this as it is a blocking issue for us. 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> 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.

9 months, 1 week

2
2
0 0

Link Time Optimization

by Quach, Brian

Hi, does TF-M use LTO? I didn't see any flags to disable it in toolchain_GNUARM.cmake. I think for GCC, it's enabled by default if no flag is set. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

9 months, 2 weeks

4
7
0 0

TF-M v2.2.0 releases

by Anton Komlev

Hello, We're kicking off the release process for TF-Mv2.2.0, starting with the TF-Mv2.2.0-RC1 tag. As part of this release phase, we're also updating the previous version to TF-Mv2.1.2, which includes critical bug fixes and support for new platforms. New TF-Mv2.1.2-RC1 tag will follow shortly. After completing initial testing on the reference platform and addressing all identified issues, we'll reach out to platform owners to verify TF-M on platforms not available in LAVA. Please note, the verification might be requested on a different tag by that time. Let me remind that the code is not frozen, and development can be continued on the main branch as described in TF-M Release Process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Thanks, Anton

9 months, 2 weeks

1
2
0 0

SPM LOG LEVEL

by Michael Khoyilar

Hi Team, I am setting the TFM_SPM_LOG_LEVEL to DEBUG in platform config.cmake. Yet it is getting overwritten by TFM_SPM_LOG_LEVEL_SILENCE. Is there any other place I need to look for? Thanks. Michael KH # LOG LEVEL set(TFM_SPM_LOG_LEVEL TFM_SPM_LOG_LEVEL_DEBUG CACHE STRING "Set default SPM log level as DEBUG level")

9 months, 3 weeks

2
1
0 0

Build Error for Regression Tests for RP2350

by no name

10 months

2
2
0 0

A delay of TF-M release v2.2.0

by Anton Komlev

Hello, TF-M release v2.2.0 is unfortunately delayed for about a month. The new tentative start date is the end of February with a goal to complete the release at the middle of March. The main reasons of the delay are: * Delays in PSA certification of RPi2350 platform * An opportunity to accommodate of Mbed TLS v3.6.3 planned on February * Limited availability of TF-M maintainers Thanks, and sorry for the possible inconveniences caused be this delay, Anton

10 months

1
1
0 0

Toolchain related questions

by Anton Komlev

Hello, Following the Tech Forum yesterday I am repeating the questions asked at the time. Please share your opinions * Do we need C++ support on S side? * CLANG/LLVM toolchain name * toolchain_CLANG.cmake vs toolchain_LLVM.cmake * Can we drop the support of -march -mtune options in favor of -mcpu only? * Can we limit supported toolchains to the earliest version with m55 support? In other words: is there anyone who must use toolchains earlier than in the table? Toolchain Cortex-M55 support since Release Date ArmClang V6.14 March 2020 GNU Arm Embedded Toolchain V10. December 2020 LLVM Embedded Toolchain for Arm V11.0.0 September 2020 IAR Embedded Workbench V8.50 November 2020 Thanks, Anton

10 months

1
0
0 0

Announcement: Expansion of the TF-M Maintainer Team

by Anton Komlev

Hi Everyone, Following today's announcement in the Tech Forum, I am pleased to share that the TF-M maintainer team is expanding. We warmly welcome back David Hu (davidhuzj(a)gmail.com<mailto:davidhuzj@gmail.com>) to the maintainer team! David has been a key contributor and TF-M maintainer for several years. After a brief pause, he has kindly agreed to resume his role, overseeing TF-M changes once again. Thank you, David, for your continued commitment and contributions to the project! All the best, Anton

10 months

1
0
0 0

attestation EAT version

by Quach, Brian

Hi, In TF-M v2.0, Initial_attestation.h says: * The initial attestation token is planned to be aligned with future version of * Entity Attestation Token format: * https://tools.ietf.org/html/draft-mandyam-eat-01 But that spec is expired and superceded with the following. Is the implementation aligned with the following spec? If so, what version of this spec is actually supported? https://datatracker.ietf.org/doc/draft-ietf-rats-eat/02/ Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

10 months, 1 week

2
1
0 0

A new repository for PSA Crypto drivers

by Anton Komlev

Hello, A new repository for PSA Crypto drivers has been created. Please review and provide feedback on the initial commit, which includes the introduction and licensing statements: https://review.trustedfirmware.org/c/share/tf-psa-crypto-drivers/+/36005 Thanks and best regards, Anton

10 months, 1 week

1
0
0 0

Firmware Upgrade in RAM_LOAD mode

by Julien Beraud

Hello Everyone, We are currently working on TF-M for the firmware of our Cortex-M55 based core, part of a bigger platform including a cortex-A based application processor, a bit like the corstone1000. We use the RAM_LOAD boot mode of TF-M/MCUBoot and we want to implement an upgrade strategy based on 2 banks, and a switch to decide which bank to boot from. I have a few questions regarding some design choices. I hope someone can answer them. Please correct me if some of my assumptions are wrong. * For the generic Firmware Upgrade partition, are there plans to support the RAM_LOAD mode ? Do you have suggestions about what is missing or how it should be done ? * Currently, MCUBoot in RAM_LOAD mode only supports booting the slot with the highest version. Do you think it is realistic to try and integrate another boot mode in MCUBoot that matches our needs ? I'm asking this because I noticed that the corstone1000 platform has been developed working around this limitation by changing the flash_map at platform initialization in order to abstract the problem from MCUBoot completely. Thank you and all the best, Julien

10 months, 2 weeks

3
5
0 0

About PSA ITS API power failure protection

by Abel Barreira Rodriguez

Hi all, I would like to know if the PSA ITS is protected in case tearing cases (power failure) happening during write/erase in the internal flash, using `psa_its_set()` or `psa_its_remove()`, please. Thanks a lot. Best regards, Abel.

10 months, 2 weeks

1
0
0 0

FW: TFM build error

by Michael Ji

Could you please help with my issue? Thank you! From: Michael Ji Sent: Friday, February 14, 2025 4:15 PM To: Raef.Coles(a)arm.com; Anton.Komlev(a)arm.com Subject: TFM build error Hi Raef and Anton: I am following the steps in this webpage to build tfm on my Windows laptop: https://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.ht… All my steps are successful till I ran this command below and got error (FYI - I am using the platform arm/mps2/an521 and GNU ARM compiler): [cid:image001.png@01DB7EFB.878CE310] Could you share your insight on how to resolve this? Thank you very much! Best, Michael

10 months, 3 weeks

3
8
0 0

Removing PSA_IOT_PROFILE_1 attestation token profile

by David Vincze

Hi all, We would like to remove PSA_IOT_PROFILE_1<https://review.trustedfirmware.org/q/topic:%22remove-psa_iot_1%22> which is an early attestation token profile (used for the original implementation of the PSA Initial Attestation service) and has been superseded by profile PSA 2.0.0 (https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#nam…). The above patches include: * Change the default token profile configuration to: ATTEST_TOKEN_PROFILE_PSA_2_0_0, * Remove support for PSA_IOT_PROFILE_1. Please let us know if you have any concerns, suggestions. Best regards, David Vincze

10 months, 3 weeks

2
3
0 0

Adding Platform power control

by Quach, Brian

Hi, I'm trying to add platform power control functions (to power off/on peripherials) to the SPM. Are there any examples of this? What is the cleanest way to implement? Can it be done via adding code to source/third_party/tfm/platform/ext/target/<vendor>/ and compiling into the platform_s target? The diagram below says connection between SPM and PRoT partitions is IMPLEMENTATION DEFINED. How does the TF-M implement PRoT partitions to call the SPM? Can it be a direct API call? I did see platform_svc_handlers() but I assume that was for use by ARoT partitions (unpriviledged). DEN0063 PSA Firmware Framework: Some platforms include functionality that can only be accessed by firmware at the highest privilege level. For example, platform power control or control registers that are shared by secure and non-secure firmware. These Platform services must be implemented as part of the SPM, but the mechanism by which the NSPE firmware accesses these services is IMPLEMENTATION DEFINED. [cid:image001.png@01DB7E32.B6F3B0D0] Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

10 months, 3 weeks

3
7
0 0

Notice: switch to upstream t_cose library

by David Vincze

Hi all, I just wanted to bring to your attention that TF-M has switched<https://review.trustedfirmware.org/q/topic:%22t_cose_upstream%22> to using the upstream t_cose library (which is used during creating and validating attestation tokens). The main reason for this change is to remove the forked t_cose code from the TF-M repository, along with its maintenance needs (similarly to the QCBOR library). Additionally, it will also allow us having consistent library code across all tf.org projects. Under normal circumstances, this change should not have any impact on you – the library code is fetched automatically during build. It might happen that you encounter CI failures in connection with this change, but you will only need to rebase your patches to align with the changes in the CI. Best regards, David Vincze

10 months, 3 weeks

1
0
0 0

How to Enable Asymmetric Signing with Small Profile

by Zhang, Hao

Hi All, I have several questions. Thanks in advance for helping out. 1. I am trying to build a TF-M application for my platform with small profile with asymmetric signing module enabled. I tried using following command cmake -S . -B build -G Ninja -DTFM_PLATFORM=MY/PLATFORM -DTFM_PROFILE="profile_small" -DCRYPTO_ASYM_SIGN_MODULE_ENABLED=y. However, the asymmetric signing module is not included. More specifically, in trusted-firmware-m/secure_fw/partitions/crypto/crypto_asymmetric.c, the #if CRYPTO_ASYM_SIGN_MODULE_ENABLED is not true. From what I understand, the -DCRYPTO_ASYM_SIGN_MODULE_ENABLED=y only define the macro, but not set it to 1, therefore, the #if CRYPTO_ASYM_SIGN_MODULE_ENABLED is not true. I am wondering if there is any way I can enable -DCRYPTO_ASYM_SIGN_MODULE_ENABLED module while still staying in small profile. I am aware that the default CRYPTO_ENGINE_BUF_SIZE might not be enough and I am willing to override it with a command line flag. Preferably, I would not want to enable asymmetric module in config.cmake as I only want to enable it for one specific application. 1. If to build with Zephyr and have TF-M as a module, is there anyway to enable asymmetric signing module given a small profile (I actually care more about this question than first question) 1. Just out of curiosity, how do you use menuconfig in TF-M. I did try -DMENUCONFIG=ON, but the compiler complains CMake Error at config/kconfig.cmake:31 (file): file STRINGS file "trusted-firmware-m/config/../platform/ext/target/MY/PLATFORM/preload.cmake" cannot be read. Call Stack (most recent call first): config/kconfig.cmake:174 (convert_normal_cmake_config_to_kconfig) CMakeLists.txt:26 (include) I thought preload.cmake is no longer required. Thank you very much! Best regards, Hao

10 months, 3 weeks

2
2
0 0

platform_sp_system_reset

by Quach, Brian

Hi, I noticed this FIXME note in platform_sp.c. Is it still valid? If so, why does it only work with Isolation level 1? I thought system reset is typically an NVIC register write and platform SP should be able to do that. enum tfm_platform_err_t platform_sp_system_reset(void) { /* FIXME: The system reset functionality is only supported in isolation * level 1. */ tfm_platform_hal_system_reset(); return TFM_PLATFORM_ERR_SUCCESS; } Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

11 months

1
0
0 0

Clarification on boot seed

by Augusto Cesare Zanellato

Hi, I'm doing a PoC on initial attestation for an university project using a RP2350 board and I'm not really understanding why boot seed is stored in OTP, shouldn't it be a value changing on each boot? Pico SDK conveniently exposes one via a ROM function (rom_get_boot_random). Another similar doubt I have is w.r.t. implementation id, couldn't it be read from the board id (pico_get_unique_board_id)? Board id is factory programmed in otp so it should actually be unique. Best Regards, Augusto Zanellato

11 months

4
4
0 0

GCC 13.3 support

by Quach, Brian

Hi, is GCC 13.3 supported by the TFM build? Has anyone tried it? I see the documentation says v7.3.1+. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

11 months, 1 week

2
3
0 0

Re: Inquiry on Overriding ITS Parameters in TF-M via Zephyr

by Jain, Saurabh

Hi Anton Thank you for your response. Let me break it down a bit. 1. We have several subsystems running on the non-secure side that require certain sensitive metadata to be stored in ITS. 2. Default values of ITS parameters are insufficient. 3. While building the Zephyr app with TF-M, NS-side (during build) passes these overriding values to CMake, which adds the specified preprocessor definitions to the compiler flags of TF-M, ensuring they are available during compilation. 4. Zephyr already has the harness for this flow. This entire flow currently doesn’t work if we don’t explicitly use these preprocessors in TF-M CMake files. Using a custom profile is not feasible for us because the overriding values are provided by the NS side based on their specific needs. Additionally, even when we attempt to provide these parameters through the command line while building only TF-M (without NS-side), we encounter the same warning: "Manually-specified variables were not used by the project." This warning indicates that these parameters are not being utilized in the CMake scripts (which make sense). I guess the question would be is there a way to override these parameters from command-line, while being platform agnostic? If not, is there any specific reason we chose not to, other than this approach could potentially override the platform specific configuration, like you suggested? We would appreciate any guidance or suggestions on how to properly handle this scenario. If needed, we can discuss this further in the next TF-M Tech forum, like you suggested. Regards Saurabh On 1/24/25, 12:47 PM, "Anton Komlev via TF-M" <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi Saurabh, If I understand you correctly, you're looking to modify the ITS_MAX_ASSET definition, which is a build-time option and cannot be changed post S-side build. Could you please explain your scenario for wanting to update it from the NS-side? You're correct that a platform can redefine certain options which is intended behavior, allowing platforms to either override or verify these settings. For more details, you can refer to the TF-M configuration priorities here: https://trustedfirmware-m.readthedocs.io/en/latest/configuration/index.html… <https://trustedfirmware-m.readthedocs.io/en/latest/configuration/index.html…>. The highest priority is the command line, which can override options even those defined in platforms. We should proceed cautiously with this approach, as there might be reasons why platforms alter the default configuration. A recommended alternative is to create a custom profile and place all your options there, though some platforms might still overwrite them as expected. We can discuss this further in the next TF-M Tech forum if you wish. Hope that helps, Anton -----Original Message----- From: Jain, Saurabh via TF-M <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org>> Sent: Thursday, January 23, 2025 7:47 PM To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Inquiry on Overriding ITS Parameters in TF-M via Zephyr Hi All, We are developing a platform using TF-M with Zephyr running on the Non-Secure (NS) side. As part of our requirements, we need to override certain ITS-related parameters, such as ITS_MAX_ASSET, from the NS side. Zephyr provides a mechanism for this through Kconfig.tfm under modules/trusted-firmware-m, which includes symbols like TFM_ITS_MAX_ASSET_SIZE_OVERRIDE. When enabled, these configurations are passed to the TF-M build system via TFM_CMAKE_ARGS through CMake under modules/trusted-firmware-m. However, we observe that TF-M does not seem to support external overrides for these parameters. This results in the CMake warning: "Manually-specified variables were not used by the project." As a result, the overrides are ignored. Currently, we address this by explicitly checking for external definitions of ITS_MAX_ASSET in platform-specific TF-M CMake files. While this works, it is platform-specific. We would like to confirm: 1. Is there an existing platform-independent method to achieve such overrides that we may have missed? 2. If not, would the community be open to adding support for this functionality so it can be upstreamed and benefit other platforms? Looking forward to your input. Best regards, Saurabh -- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org <mailto:tf-m-leave@lists.trustedfirmware.org> -- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org <mailto:tf-m-leave@lists.trustedfirmware.org>

11 months, 2 weeks

2
1
0 0

Inquiry on Overriding ITS Parameters in TF-M via Zephyr

by Jain, Saurabh

Hi All, We are developing a platform using TF-M with Zephyr running on the Non-Secure (NS) side. As part of our requirements, we need to override certain ITS-related parameters, such as ITS_MAX_ASSET, from the NS side. Zephyr provides a mechanism for this through Kconfig.tfm under modules/trusted-firmware-m, which includes symbols like TFM_ITS_MAX_ASSET_SIZE_OVERRIDE. When enabled, these configurations are passed to the TF-M build system via TFM_CMAKE_ARGS through CMake under modules/trusted-firmware-m. However, we observe that TF-M does not seem to support external overrides for these parameters. This results in the CMake warning: "Manually-specified variables were not used by the project." As a result, the overrides are ignored. Currently, we address this by explicitly checking for external definitions of ITS_MAX_ASSET in platform-specific TF-M CMake files. While this works, it is platform-specific. We would like to confirm: 1. Is there an existing platform-independent method to achieve such overrides that we may have missed? 2. If not, would the community be open to adding support for this functionality so it can be upstreamed and benefit other platforms? Looking forward to your input. Best regards, Saurabh

11 months, 3 weeks

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

11 months, 4 weeks

1
0
0 0

Slow PSA Protected Storage (PS) API write operations

by Ylinen, Juha

Hi Everyone, During our investigation into the slow write operations of the PSA Protected Storage (PS) API, we identified that numerous (>10) flash erase calls occur when executing psa_ps_set() or psa_ps_remove(). A significant portion of these erase calls is linked to the rollback protection mechanism, specifically for updating Non-Volatile (NV) counters. A potential improvement we are considering is to differentiate rollback protection requirements based on the type of flash memory being used. * For systems utilizing internal flash, we suggest possibility to disable rollback protection when encryption is enabled. This improves speed of write and remove operations and reduces the flash wear. * Rollback protection should be enabled when protected storage is located in external flash to ensure data integrity and security Currently, there is a Kconfig option, CONFIG_TFM_PS_ROLLBACK_PROTECTION, to disable rollback protection. However, a build-time check requires that PS encryption is also disabled, as referenced here: https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git… To better align rollback protection with the type of flash memory, there is the possibility of updating the macro rule. This could involve either removing the existing rollback protection check or adding a new rule based on the flash type, enforcing rollback protection only for external flash. While introducing a Kconfig option for the flash memory type is a potential solution, it raises concerns about reduced security in cases of misconfiguration. Your insights on how to address this would be invaluable. Thank you in advance for your input! Best regards, Juha Ylinen

12 months

1
0
0 0

MPU driver in beta version

by Zhang, Hao

Hi TF-M community, I find the arm provided a mpu driver https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/main/platform…, however, it is in beta version. I am wondering anyone in the mailing list might know if the driver is intended to be finailized. Best regards, Hao

1 year

2
2
0 0

[RFC] Add a RPC callback to identify mailbox IRQ source

by David Hu

Hi all, When TF-M RPC callbacks were introduced to support multi-core mailbox handling, typically only a single mailbox interrupt source was available on a multi-core system. Therefore, in the initial design, RPC callback handle_req(void) doesn't pass any information of mailbox interrupt source to platform mailbox drivers. Recently, some platforms, such as RSE based ones, consists of multiple mailbox interrupt sources. I notice that those platforms fetch and parse mailbox messages in their mailbox IRQ handlers. It can take quite a long time in IRQ handlers and doesn't get full benefits from Second-Level Interrupt Handling. Due to the limitation of RPC callback handle_req(void), those platforms are unable to move mailbox message handling to threaded NS Agent Mailbox SP context. I'd propose to add a new RPC callback handle_req_irq_src(irq_src) to pass mailbox interrupt source information to platform drivers. With this information, platform drivers can identify the source and select the corresponding handler to fetch, parse and dispatch mailbox messages in NS Agent Mailbox SP context, instead of in IRQ handlers. If platform owners are all satisfied with this new RPC callback, I also wonder if it can replace the existing handle_req() in future, assumed no backward compatible issues are raised. Please can you review the patches: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34317/1? Any comment is welcome. Thank you. Best regards, David Hu

1 year

1
0
0 0

Hybrid Platform NSPE (Solution.2)

by Nicola Mazzucato

Hi All, I pushed for initial testing and review a series of patches to support the Scheduling-NSPE Hybrid Platform Solution (aka Solution-2). A "Hybrid Platform" is an extension of the MULTICORE case where applications also run in the NS-side of the core that hosts TF-M SPE. Patches can be found at this gerrit topic (hybrid-plat-nspe): https://review.trustedfirmware.org/q/topic:%22hybrid-plat-nspe%22. All the patches are Request-For-Comments (RFC) and the community is welcome to provide feedback on such changes/proposal. The "Hybrid Platform" support coming to TF-M has been discussed a few times in the past and slides and recordings are available in the technical forum past events: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/. This presented solution follows the main ideas presented in the past. However, since the last presentations, some adjustments have been done, in particular around: - naming: we won't use numbers for solutions, like Sol.1, 2 etc, but instead we name them: _SPE, _NSPE etc, to make immediately clear the use-case. - "simple first" approach: we aim to provide a "simple" solution in the attempt to provide an initial reference and keep the core code readable, compact and testable. If there are significant use-cases to be included, please share your feedback and we'll find a best solution. Kindly expect some changes on these proposed patches above while I rebase, perform some other tests and need to refactor some portions. Expected timeline for Hybrid Platform Solution: - SPE-support: already merged into mainline - NSPE-support (this series above), merge within two months (end of Feb-25), provided that there will be no disruptive changes - BALANCED-support: a new set will be available around the middle of 2025 (subject to change). Many thanks in advance and happy New Year. Best regards, Nicola Nicola Mazzucato (7): [RFC 1/7] SPM: tfm_rpc: Add `process_new_msg handler` [RFC 2/7] tfm_spe_mailbox: Add `mailbox_process_new_msg` handler [RFC 3/7] ns_agent_mailbox: Add NS_AGENT_MBOX_PROCESS_NEW_MSG_SIGNAL aux service [RFC 4/7] SPM: backend_ipc: Conditionally assert MBOX signal on SCHED_TYPE [RFC 5/7] SPM: tfm_multi_core: Record and clear mailbox IRQ via multi_core API [RFC 6/7] docs: hybrid_platform: Add documentation [RFC 7/7] Config Base for Hybrid Platform Nicola Mazzucato (he/him/his) | CE-Software Group | Arm 110 Fulbourn Rd, CB1 9NJ, Cambridge UK At Arm we work flexibly and globally, if you receive this email outside of your usual working hours please do not feel that you have to respond immediately. 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.

1 year

1
0
0 0

FPU S16-S31 registers

by Roman.Mazurak＠infineon.com

Hi all, We found the problem with FPU S16-S31 registers if FPU is enabled and compiler uses S16-S31 FPU registers on CM33 non-secure code with TZ agent. SPM doesn't save/restore S16-S31 registers properly nor by PendSV neither by FLIH SVC handler. I created a patch for this problem: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34202 The second problem I found is related to lazy stacking. It's possible that float point context will be stacked by MCU when FLIH is switching to/from background thread after a new boundary is applied. As result it's possible that the non-privileged code will no have access to PSP stack of suspended partition because a new MPU settings are applied. Please review a patch for this problem: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34203 Regards, Roman.

1 year

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M