- TF-M - lists.trustedfirmware.org

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 week, 2 days

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

2 weeks, 1 day

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

2 weeks, 1 day

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

2 weeks, 2 days

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

2 weeks, 2 days

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

2 weeks, 2 days

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

2 weeks, 3 days

11
86
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

2 weeks, 4 days

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

3 weeks, 1 day

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>

3 weeks, 1 day

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

1 month

3
3
0 0

Proposal to deprecate Musca-S1 and BL5340_dvk_cpuapp platforms

by Anton Komlev

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

1 month

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

1 month

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

1 month, 2 weeks

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

1 month, 2 weeks

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

2 months, 1 week

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.

2 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

2 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

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

2 months, 4 weeks

2
1
0 0

Build Error for Regression Tests for RP2350

by no name

3 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

3 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

3 months, 1 week

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

3 months, 1 week

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.

3 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

3 months, 2 weeks

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

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

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

3 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

3 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

3 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

4 months

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

4 months

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.

4 months, 1 week

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

4 months, 1 week

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.

4 months, 2 weeks

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>

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

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

5 months

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

5 months, 1 week

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

5 months, 1 week

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

5 months, 2 weeks

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.

5 months, 2 weeks

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.

6 months

2
2
0 0

Re: Backwards compatibility of Protected Storage implementation (TF-M 1.8.1 -> 2.1.1)

by FLOC'H Tanguy

Hello, We are facing the same compatibility break issues, during a TF-M 1.7.0 -> 2.1.0 migration. - About the problem [1] (commit ffd13c3) Is there any plan to implement a mechanism, to migrate old Protected Storage objects, to the new format? - About the problem [2] (client id). There is also a compatibility break, on keys stored in Internal Trusted Storage (ITS). A key generated from NS, with TF-M 1.7.0, can not be read anymore after TF-M 2.1.0 migration (psa_key_attributes returns PSA_ERROR_INVALID_HANDLE). Changing client_id_limit from value -0x3c000000 to -1 makes old keys available. Is there a cleaner option, to support backward compatibility with keys created with client id = -1? Best regards, T. FLOC'H ________________________________ This electronic message and its attachments are confidential and transmitted for the exclusive use of their addressee. Should you receive this message by mistake, you are not authorized to use it for any purpose whatsoever; please delete it and notify the sender at once. LACROIX reserves the right to initiate any legal proceedings against any individual and organization in case of unauthorized use, without prejudice to possible criminal sanctions. ________________________________ Ce message et ses pièces jointes sont confidentiels et exclusivement transmis à l'usage de leur destinataire. Si vous recevez ce message par erreur, vous n’êtes pas autorisés à en faire une quelconque utilisation ; merci de le détruire et d'en avertir immédiatement l'expéditeur. LACROIX se réserve le droit de poursuivre toute entité, personne physique ou morale qui en ferait un usage non autorisé, sans préjudice d'éventuelles sanctions pénales.

6 months

2
2
0 0

connection-based MMIOVEC

by Quach, Brian

Hi, I am trying to use connection-based (instead of SFN) Crypto service with MMIOVEC, but I noticed that iovec_status is not automatically cleared so the second psa_call causes a TFM panic due to detection of a previously mapped IOVEC. FF spec says: [cid:image001.png@01DB3B6B.1D4E93F0] In tfm_crypto_call_srv(), I see the output vecs are unmapped but not the input vectors. Should the inputs be unmapped here as well? (psa_attest_get_token also does not unmap input vecs) status = tfm_crypto_init_iovecs(msg, in_vec, in_len, out_vec, out_len); if (status != PSA_SUCCESS) { return status; } tfm_crypto_set_caller_id(msg->client_id); /* Call the dispatcher to the functions that implement the PSA Crypto API */ status = tfm_crypto_api_dispatcher(in_vec, in_len, out_vec, out_len); #if PSA_FRAMEWORK_HAS_MM_IOVEC == 1 for (i = 0; i < out_len; i++) { if (out_vec[i].base != NULL) { psa_unmap_outvec(msg->handle, i, out_vec[i].len); } } #else /* Write into the IPC framework outputs from the scratch */ for (i = 0; i < out_len; i++) { psa_write(msg->handle, i, out_vec[i].base, out_vec[i].len); } Currently, to clear the connection's iovec_status, I have to call psa_close() after every psa_call() and reconnect with psa_connect() before the next psa_call() which adds overhead. Is this behavior of not automatically clearing iovec_status for connection-based services by design? As an alternative to calling psa_unmap_invecs(), I was wondering if spm_get_connection()/spm_get_idle_connection() could be modified with the following workaround to avoid needing to close/connect: #if CONFIG_TFM_CONNECTION_BASED_SERVICE_API == 1 connection = handle_to_connection(handle); if (!connection) { return PSA_ERROR_PROGRAMMER_ERROR; } if (spm_validate_connection(connection) != PSA_SUCCESS) { return PSA_ERROR_PROGRAMMER_ERROR; } /* WORKAROUND */ #if PSA_FRAMEWORK_HAS_MM_IOVEC connection->iovec_status &= 0xFFFF0000; // Clear status of input vecs #endif /* Validate the caller id in the connection handle equals client_id. */ if (connection->msg.client_id != client_id) { return PSA_ERROR_PROGRAMMER_ERROR; } /* * It is a PROGRAMMER ERROR if the connection is currently * handling a request. */ if (connection->status != TFM_HANDLE_STATUS_IDLE) { return PSA_ERROR_PROGRAMMER_ERROR; } if (!(connection->service)) { /* FixMe: Need to implement a mechanism to resolve this failure. */ return PSA_ERROR_PROGRAMMER_ERROR; } #else Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

6 months, 2 weeks

2
10
0 0

Re: Backwards compatibility of Protected Storage implementation (TF-M 1.8.1 -> 2.1.1)

by Miika Karanki

Hi Anton and Chris, Thank you for your replies. I have TFM_NS_MANAGE_NSID set to off. That does not prevent client_id translation to happen. `tfm_nspm_get_current_client_id` seems to do translation unconditionally here: https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git…. But as said, setting client_id_limit in code to -1 helps. Maybe there could be additional configuration #define whether to do translation when TFM_NS_MANAGE_NSID is off. Transition approach to convert the old PS data format to new one on the flash when reading data in new format fails sounds reasonable assuming there's no security problems involved in retrying to read the objects using the old format after a failure. Probably not. It anyways sounds better than supporting the old one "forever". At least to me, being able to do that transition would require a bit of learning what exactly was the old and what is the new layout. If there's some material in addition to source code, I'd be happy to check that. -Miika ke 27.11.2024 klo 23.01 Chris.Brand--- via TF-M ( tf-m(a)lists.trustedfirmware.org) kirjoitti: > Hi Miika, > > > > Unfortunately there have been a couple of changes to the way that PS data > is stored in flash. I hope that we are getting better at considering > backwards compatibility. In general I think that whenever we do introduce a > change like this, we need to ensure that data stored with the old layout > can still be read by newer code. > > > > I believe the patch that you’ve identified was part of the work to make PS > encryption optional. Looking at it now, I don’t see that the layout was a > necessary part of that work. Unfortunately, we’re now in a position where > there could be PS data stored on devices in this new format, so just > reverting that part of that patch would cause other problems. > > > > The bad news is that there’s another stored format change post-v2.1.1. The > good news is that we did think about existing data and introduced a build > option to read the old format. > > > > One solution to your problem would be similar to > https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/e8d48d78c166… > - a build option to support reading the old format, with stores then using > the new format. Another option would be to introduce the 1.8.1 format as an > alternative implementation i.e. a second struct inside union ps_crypto_t > and provide the 1.8.1 code as well as the current code (this would mean > picking a storage format at build time and using it forever). > > > > Regarding the client_id. You’re correct that the client_id is used as a > kind of access control (the client_id and UID together identify the stored > object). Yes, there was a major change to the way that client_ids are used, > with the mapping being added. Do you have TFM_NS_MANAGE_NSID set to ON? I > believe that if it is set to OFF then -1 is used inside TF-M to represent > all non-secure clients, which sounds like it may be what you need. > > > > Chris >

6 months, 2 weeks

3
2
0 0

Coding style update

by Antonio De Angelis

Hi all, just to point out that the coding guidelines are being updated to reflect feedback received over the years about the point of variable declaration. The majority of the code already follows this style, changing the guidelines to avoid further confusion. …/coding_guide.rst · Gerrit Code Review<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/33807/1/docs…> Please let us know if any feedback. Thanks, Antonio

6 months, 2 weeks

1
0
0 0

mbedtls 2.25 and 3.6

by Michael Khoyilar

Hi Team I am investigating the move from MbedTLS 2.25 to 3.6, however, our client uses the 2.25 currently (looks like they prefer to stay with it) and I need to provide convincing proof to move to 3.6 considering the upgrade issues that might arise. Any suggestions here that is convincing proof to do the migration to 3.6? I would appreciate your comments. Thanks Michael

6 months, 2 weeks

2
1
0 0

Backwards compatibility of Protected Storage implementation (TF-M 1.8.1 -> 2.1.1)

by Miika Karanki

Hi, I am working on an update from TF-M 1.8.1 to TF-M 2.1.1 on a board that uses encrypted Protected Storage. The board used is stm32 b_u585i_iot02a, NSPE side using Zephyr OS. I want to support field updates as well for devices already having Protected Storage objects created from NSPE. In my case, Protected Storage is created and used by TF-M 1.8.1, and I want it to remain functional after upgrading to TF-M 2.1.1. PS_CRYPTO_AEAD_ALG is set to (default) PSA_ALG_GCM. I have faced two issues with the uplift: 1. It seems commit ffd13c3 ( https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/ffd13c31d5e6…) has changed the layout how Protected Storage objects are stored into flash. With TF-M 2.1.1 and old PS data, PS init fails (or gets recreated if PS_CREATE_FLASH_LAYOUT, which I don't want since then all the existing objects would get erased). If I revert the commit (and https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git… as not to have conflicts), then the PS initialization can pass and objects are decrypted successfully. I have not been able to understand this thoroughly, but at least change in `union ps_crypto_t` struct member order is changing padding (sizeof 48 -> 40), and that in turn seems to shift at least additional data by 8 bytes via `#define PS_NON_AUTH_OBJ_TABLE_SIZE sizeof(union ps_crypto_t)`. Is this compatibility issue "a bug" in 2.1.1 or expected by design? 2. PS objects in 1.8.1 were storing client id to the object table entry to implement access control (?). With 1.8.1, the client id that got stored was -1. With 2.1.1, likely due to the Mailbox NS Agent Design Update ( https://tf-m-user-guide.trustedfirmware.org/design_docs/dual-cpu/mailbox_ns…), non-secure requests to get an object seems to pass client ID -0x3c000000 to the Protected Storage implementation. That is, client id -1 seems to be transformed to `client_id_limit`. Due to this, `psa_ps_get_info()` fails to get an object that has been previously made with 1.8.1 FW. I am able to get reading of old stored objects working by changing `client_id_limit` from value -0x3c000000 to -1 which changes to use 1-to-1 mapping when using client_id=-1. But I am unsure if this change causes some unwanted side effects. Is this the correct way to gain backwards compatibility? And if it is, would it make sense to pick https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git… into 2.1.x branch and add a configuration flag for the 1-to-1 mapping support without code change for backwards compatibility? Thanks, Miika

6 months, 3 weeks

3
2
0 0

tf-m-tests for Floating point unit

by Zhang, Hao

Hi TF-M Maintainers, I am trying to build tf-m regression tests with fpu tests on for an521 and musca_s1 (I manually enable allow fpu tests for musca_s1) from Zephyr's west build. I did that by 1. set(CONFIG_TFM_ENABLE_FP ON) in config.cmake 2. set(TEST_NS_FPU ON) in tfm_test_config.cmake But both build fails with ~/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: secure_fw/partitions/partitions/service_5/libtfm_app_rot_partition_fpu_service.a(tfm_fpu_service_test.o): in function `fpu_service_check_fp_register': ~/work/zephyrproject_adi/modules/tee/tf-m/tf-m-tests/tests_reg/test/secure_fw/suites/fpu/service/tfm_fpu_service_test.c:48: undefined reference to `dump_fp_callee' ~/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: ~/work/zephyrproject_adi/modules/tee/tf-m/tf-m-tests/tests_reg/test/secure_fw/suites/fpu/service/tfm_fpu_service_test.c:39: undefined reference to `dump_fp_callee' ~/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: ~/work/zephyrproject_adi/modules/tee/tf-m/tf-m-tests/tests_reg/test/secure_fw/suites/fpu/service/tfm_fpu_service_test.c:42: undefined reference to `populate_callee_fp_regs' ~/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: secure_fw/partitions/partitions/service_5/libtfm_app_rot_partition_fpu_service.a(tfm_fpu_service_test.o): in function `fpu_service_check_fp_register_after_ns_inturrept': ~/work/zephyrproject_adi/modules/tee/tf-m/tf-m-tests/tests_reg/test/secure_fw/suites/fpu/service/tfm_fpu_service_test.c:92: undefined reference to `fp_func_jump_template'. I modified line 16-19 of https://github.com/zephyrproject-rtos/tf-m-tests/blob/a1a178d8c1f3c75763511… to below target_sources(tfm_app_rot_partition_fpu_service PRIVATE tfm_fpu_service_test.c ../fpu_tests_common.c ) Then, it starts building successfully. Is there anything particular I am missing. Thank you! My tf-m tests version is 502ea90105ee18f20c78f710e2ba2ded0fc0756e (Merge pull request #11 from tomi-font/update_2.1.1)for https://github.com/zephyrproject-rtos/tf-m-tests. Best regards, Hao

7 months

2
1
0 0

FPU use with TF-M

by Jain, Saurabh

Hi We’re developing a platform using TF-M and would like to get some clarity on using FPU on Secure and Non-Secure side. The idea is to let NS application decide if it wants to use FPU. Currently, we are enabling CONFIG_TFM_ENABLE_FP which means we’re setting CPACR.CP10, CPACR.CP11 and enabling NSACR.CP10, NSACR.CP11. With this configuration: 1. Is it okay if SE perform some FP operation which would set CONTROL.FPCA and return to NSE (CPACR_NS.CP10 and CPACR_NS.CP11 are not set) while CONTROL.FPCA is still set? 2. With the above configuration, if NSE wants to use FPU, it simply needs to enable CPACR_NS.CP10 and CPACR_NS.CP11. Is this correct? 3. If SE doesn’t require FPU, we could simply enable CONFIG_TFM_ENABLE_CP10CP11 (CONFIG_TFM_ENABLE_FP is OFF) and NS app would still be able access FPU after enabling CPACR_NS bits? 4. There is a hard requirement for the -mfloat-abi to be consistent for S, NS and all the static libraries used? Thank you in advance! Best Saurabh Jain

7 months

2
1
0 0

FreeRTOS OTA PAL PSA status

by Bohdan.Hunko＠infineon.com

Hi all, I have found this interesting repo repo https://github.com/Linaro/freertos-ota-pal-psa I was wondering whether this is official PSA FW UPDATE API support for FreeRTOS, and is it still supported/maintained? 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

3
3
0 0

TF-M Small Profile with Initial Attestation - Related Query

by Srinivasan, Jayashree

Hello, I have been trying to test the initial attestation feature using the regression build for a platform that we are developing. TF-M small profile has been configured, which enables symmetric key-based attestation. On running the regression tests, the TFM_NS_ATTEST_TEST_2001 testcase fails. On further debugging, I found that the static buffer that mbedtls uses for its allocation is not sufficient ( CRYPTO_ENGINE_BUF_SIZE = 0x400 in small profile). When I increase the buffer size to 0x500, the testcase passes. Therefore, I wanted to know if this change needs to be adopted upstream or if I might be overlooking something on my end. Any leads in this regard would be helpful. Thanks, Jayashree

7 months, 1 week

2
2
0 0

ARM PPC Driver invocation

by Michael Khoyilar

Hi Team, Thanks for you helps. This this time I want to know how does PPC functions will be called from application to set a possible feature? The question is how PPC functions are exposed to outside world? I know we have a common ARM API in under platform/ext/driver/Driver_PPC.h I am mapping my PPCs to this API, however wondering how they might be called that refer to my specific PPCs ? I am not using the ARM naming for my PPCs drivers, for example not using the name Driver_AHB_PPCEXP0 (using the name Driver_APB_PPCBASE0). Thank you again. Michael

7 months, 1 week

2
1
0 0

Use of ROM address - flash_layout.h

by Michael Khoyilar

Hi all, I am getting to know the TF-M, yet I do not understand the following comment and code where ROM (Read Only) is mentioned and its address used to store Code Data (flash_layout.h)!! Can someone help me understand this better? Thanks BR Michael /* Use flash memory to store Code data */ #define S_ROM_ALIAS_BASE (0x10000000) #define NS_ROM_ALIAS_BASE (0x00000000)

7 months, 2 weeks

3
3
0 0

TF-M v2.1.1 release

by Anton Komlev

Hello, We are starting releasing TF-Mv2.1.1 targeted for PSA certification and LTS support. TF-Mv2.1.1-RC1<https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/…> tag is placed on all repositories. 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

7 months, 3 weeks

1
2
0 0

Query on Storing OTP-Provisioned Values in ITS during Service Initialization

by Jain, Saurabh

Hello We have some platform-specific values provisioned in OTP that we need to retrieve and store in ITS (with encryption enabled) during initialization. We could do something similar to template file crypto_nv_seed.c, where the tfm_plat_crypto_provision_entropy_seed function is invoked from tfm_crypto_engine_init within secure_fw/partitions/crypto/crypto_init.c. However, we have a few questions: 1. Adding something similar in tfm_its_init won’t work as psa_its_* would again call into ITS via SPM which could be a problem? Also there is no hook in its_init to add platform specific routines as well? Is this correct? 2. Since crypto_init.c is part of secure_fw/, we’re uncertain about adding new platform-specific routines directly in tfm_crypto_engine_init. If this is not advisable, could you suggest an ideal place for implementing this functionality? 3. Regarding the SFN model, our understanding is that SPM initializes all partitions (and their respective services) before transitioning control to the NS side. Could you confirm if this is correct? We want to make sure that the provisioned values are stored in ITS before receiving request from NS client. Thank you for your guidance! Saurabh

7 months, 3 weeks

2
2
0 0

Open CI is currently down

by Antonio De Angelis

Open CI infrastructure has been down since this morning and currently still not working. Will post updates to the mailing list once they are available. Thanks, Antonio

7 months, 3 weeks

1
1
0 0

ITS Encryption

by Jain, Saurabh

Hi All I am quite new to TF-M and would like some insight into the query below. I appreciate any help you can provide. We're adding encryption support for ITS and for nonce requirement, we're thinking of accessing TRNG which is part of the crypto partition. Now, we're aware of the possible cyclic dependency issue with the IPC model but since we're using the SFN model, will it be okay to access crypto service(TRNG) from ITS? In other words, would cyclic dependency be a concern in SFN model provided there are no limitations on hardware? Thanks in advance. Saurabh

7 months, 4 weeks

3
3
0 0

Notice of platform deprecation: TC2

by Jackson Cooper-Driver

Hi all, A heads up that the Total Compute 2022 (TC2) platform is due to be deprecated. If there is no objection, I will go ahead and remove TC2 from the TF-M codebase a month from now (25/11/24). Thank you. Thanks, Jackson

7 months, 4 weeks

1
0
0 0

increased interrupt latency when calling the PSA PS API

by Fontanilles, Tomi

Hi all, I'm currently looking into an issue reported internally where the maximum latency for a zero-latency, priority 0 interrupt dramatically increases during a call to the PSA Protected Storage (PS) API. The maximum interrupt latency goes up ~10-fold, or even some more at times (it varies), and this is not acceptable to code running on the NS side for normal operation. It's as simple as calling psa_ps_set(1, 4, buf, PSA_STORAGE_FLAG_NONE) once. During that call (which I am told was also seen to be unreasonably long: 600ms for 4 bytes, 1s for 1000 bytes), the maximum interrupt latency goes up. It (the maximum) seems to not vary too much even if increasing the size of stored assets (tested up to 4000 bytes), though it can get up to 20 times higher than the normal interrupt latency. Also, other functions were tested (psa_generate_random(), psa_hash_compute()). Those don't provoke an increased interrupt latency. Maybe it's only about the PS, or maybe some other calls can provoke that as well. Does someone have an explanation for that? And even more importantly, can that interrupt latency be reduced, ideally down to normal levels? Thanks in advance. Tomi

8 months

2
5
0 0

Set PSA_2_0_0 as default attest profile and removal of PSA_IOT_PROFILE_1

by Tamas Ban

Hi, We are going to set the PSA_2_0_0 profile as the default for the initial attestation service. This will impact which claims are included in the token and their key values. More details are here: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-24.html Changes on review: https://review.trustedfirmware.org/q/topic:%22attest_profile_update%22 As a follow-up action, the PSA_IOT_PROFILE_1 is being deprecated. We are planning to remove it from the code base as well. To figure out the timing of this we would like to collect some data: * If you are using the PSA_IOT_PROFILE_1 please let us know what would be a feasible time for you to switch over the PSA_2_0_0 profile. Thanks! Best regards, Tamas Ban

8 months, 1 week

3
2
0 0

Discussion on TF-M Copyright notices update

by Anton Komlev

Hello, I would like to open discussion on TF-M copyright notice unification following other projects in TrustedFirware.org<https://www.trustedfirmware.org/> which already adopted Linux Foundation copyrights<https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-…>. With the change TF-M copyright notice will be unified to: Copyright (c) XXXX[-YYYY], The TrustedFirmware-M Contributors. All rights reserved. The change to the contribution process is proposed here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/31664 Please share your thoughts on the subject. I plan to bring this topic to the tech forum agenda on Thursday. Please join the discussion. Thanks, Anton

8 months, 2 weeks

1
1
0 0

PSA Certification for TF-M

by Zhang, Hao

Hi TF-M committee, I have a question regarding PSA certification. Am I understanding correctly that if a platform wants to be ported to TF-M and the product wants to pass PSA certified, the TF-M version needs to come from a certain LTS tag release (e.g. TF-M v2.1.0<https://github.com/TrustedFirmware-M/trusted-firmware-m/tree/TF-Mv2.1.0> with commit 0c4c99b<https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/0c4c99ba33b3…> that was pushed 5 months ago). However, Zephyr v3.7.0 is using TF-M version<https://github.com/zephyrproject-rtos/zephyr/blob/v3.7.0/west.yml#L330C17-L…> that is updated after TF-M v2.1.0. Does that means efforts need to be done to manually modify west.yml in Zephyr to roll back to the tag release of v2.1.0 for PSA certification? Thank you very much, Best, [https://opengraph.githubassets.com/f92ee5eaaedaf25d7ae17b5e8fc073a1573b0f31…]<https://github.com/zephyrproject-rtos/zephyr/blob/v3.7.0/west.yml#L330C17-L…> zephyr/west.yml at v3.7.0 · zephyrproject-rtos/zephyr<https://github.com/zephyrproject-rtos/zephyr/blob/v3.7.0/west.yml#L330C17-L…> Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures. - zephyrproject-rtos/zephyr github.com [https://opengraph.githubassets.com/685e753ecccd8431b5e0c4ed32fb794a49e2bcb3…]<https://github.com/TrustedFirmware-M/trusted-firmware-m/tree/TF-Mv2.1.0> GitHub - TrustedFirmware-M/trusted-firmware-m at TF-Mv2.1.0<https://github.com/TrustedFirmware-M/trusted-firmware-m/tree/TF-Mv2.1.0> Read-only mirror for Trusted Firmware-M. Contribute to TrustedFirmware-M/trusted-firmware-m development by creating an account on GitHub. github.com Best regards, Hao

8 months, 2 weeks

3
6
0 0

Security vulnerability notice - Unchecked user-supplied pointer via mailbox messages may cause write of arbitrary address

by Anton Komlev

Hello, This email is a notification of a new security vulnerability reported to TF-M by Infineon Technologies AG, in collaboration with: Tobias Scharnowski, Simon Wörner and Johannes Willbold from fuzzware.io. Unchecked user-supplied pointer via mailbox messages may cause write of arbitrary address. Please find the security advisory attached. The fix has been merged on the latest main branch tfm_spe_mailbox: Do not write-back on input vectors checks failure<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/31512> We're preparing a hotfix release v2.1.1 to include fixes for this vulnerability and bugs reported till that date via TF-M issue tracker: https://github.com/TrustedFirmware-M/trusted-firmware-m/issues?q=is%3Aissue Thanks and best regards Author

8 months, 3 weeks

1
0
0 0

QEMU usage

by Matthew Dalzell

Hi everyone, It has come to our attention that QEMU is no longer able to run the regression tests in a timely manner, and before we go ahead and outright disable them, we would like to know if anyone is using QEMU for their platform testing. If so, please reply to this message and we can have further discussion on the point. Thanks, Matt

8 months, 3 weeks

2
1
0 0

Re: Looking for suggestions about make Mbed TLS APIs non-secure callable APIs on armv8m

by Shebu Varghese Kuriakose

+ TF-M mailing list From: David Horstmann via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Tuesday, September 24, 2024 5:14 PM To: mbed-tls(a)lists.trustedfirmware.org; Lee, William <William.Lee(a)garmin.com> Subject: [mbed-tls] Re: Looking for suggestions about make Mbed TLS APIs non-secure callable APIs on armv8m Hi William, Since Mbed TLS is a cross-platform library, we don't deal directly with TrustZone-M. However, if I have understood correctly, I think your usecase is solved by the Trusted Firmware M (TF-M) project[1], which is an implementation of secure firmware that provides cryptography services via non-secure-callable APIs. TF-M uses Mbed TLS internally and implements the PSA Certified Cryptography API[2]. The Crypto Service Integration Guide[3] in the documentation should be a good starting point for what you are trying to do. I hope that helps, David Horstmann Mbed TLS developer [1] https://www.trustedfirmware.org/projects/tf-m [2] https://www.psacertified.org/getting-certified/crypto-api-compliance/ [3] https://trustedfirmware-m.readthedocs.io/en/latest/integration_guide/servic… [https://www.trustedfirmware.org/images/social-media-image.png]<https://www.trustedfirmware.org/projects/tf-m> TrustedFirmware-M (TF-M)<https://www.trustedfirmware.org/projects/tf-m> TrustedFirmware-M (TF-M) implements the Secure Processing Environment (SPE) for Armv8-M, Armv8.1-M architectures or dual-core platforms. www.trustedfirmware.org<http://www.trustedfirmware.org> ________________________________ From: Lee, William via mbed-tls <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> Sent: 24 September 2024 15:08 To: mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> <mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>> Subject: [mbed-tls] Looking for suggestions about make Mbed TLS APIs non-secure callable APIs on armv8m Hi Mbed TLS, I am looking for some suggestions about make some (or all) Mbed TLS APIs non-secure callable APIs on armv8m. The background is that I am going to have a secure firmware that provides encryption services by building part (or whole) of Mbed TLS into that firmware and make those original mbedtls_x APIs non-secure callable, so the existing non-secure firmware could link those non-secure callable APIs and use them. Some of my thoughts: (1) The easiest way to do it I can think of is just add the attribute "cmse_nonsecure_call" to those APIs' declaration (or use a macro to wrap the attribute for conditional build to not impact others don't want it), but I do not think this modification could be accepted by upstream 🙂. (2) So my another thought is duplicate all header files and put them under another folder, assuming it is my-include folder, then I can do whatever I want to my-include folder, but there is also a problem I can think of: a merge/compare burden between include and my-include folder after I have updated Mbed TLS. I really appreciate other suggestions! Thanks, William

9 months

2
1
0 0

Re: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform

by Mark Chen

Hi all, I am working on integrating our IP(PUFcc) into TF-Mv2.1.0, with the PUFcc located at address 0x51700000. The PUFcc can be access on bl2 stage, however, it cannot be access on booting tf-m stage. The exception log as below: [cid:image002.png@01DAEFC7.96FE4EB0]FATAL ERROR: HardFault Here is some context for the exception: EXC_RETURN (LR): 0xFFFFFFF1 Exception came from secure FW in handler mode. xPSR: 0x00000003 MSP: 0x31000B18 PSP: 0x31000BF8 MSP_NS: 0xFFFFFFFC PSP_NS: 0xFFFFFFFC Exception frame at: 0x31000B18 R0: 0x31000B60 R1: 0x00000000 R2: 0x0000001B R3: 0x00000002 R12: 0x00000000 LR: 0x38009EF7 PC: 0x3800AB02 xPSR: 0x6100000B Callee saved register state: R4: 0xFFFFFFF9 R5: 0x31000B60 R6: 0x00000002 R7: 0x00000002 R8: 0x38030F24 R9: 0x0000001B R10: 0x00000011 R11: 0x38030F11 CFSR: 0x00008200 BFSR: 0x00000082 BFAR: 0x00000004 MMFSR: 0x00000000 MMFAR: Not Valid UFSR: 0x00000000 HFSR: 0x40000000 SFSR: 0x00000000 SFAR: Not Valid The diff patch as below: [cid:image003.png@01DAEFC7.96FE4EB0]--- a/secure_fw/spm/core/main.c +++ b/secure_fw/spm/core/main.c @@ -56,6 +56,9 @@ static fih_int tfm_core_init(void) */ SPMLOG_INFMSG("\033[1;34mBooting TF-M "VERSION_FULLSTR"\033[0m\r\n"); + uint32_t* p_s = (uint32_t *)0x51700000; + printf("p_s = %08x\n", (uint32_t)*p_s); Could you provide any suggestions on this issue? Best regards, Mark Chen Research & Development Division II PUFsecurity Corporation Tel: 886-3-5601010 ext. 3110 Fax: 886-3-5601177 Email: mark(a)pufsecurity.com<mailto:mark@pufsecurity.com> [cid:image001.png@01DAEFC5.FD4AE270] From: Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>> Sent: Thursday, August 1, 2024 12:12 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: Randy Liu <randyliu(a)pufsecurity.com<mailto:randyliu@pufsecurity.com>>; Victor Huang <victor(a)pufsecurity.com<mailto:victor@pufsecurity.com>>; Neil Chen <neilchen(a)pufsecurity.com<mailto:neilchen@pufsecurity.com>>; Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com<mailto:Shebu.VargheseKuriakose@arm.com>> Subject: Re: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform Hi Anton, Thank you and enjoy your time!!! Best, Andy ________________________________ 寄件者: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> 寄件日期: Wednesday, July 31, 2024 11:34:48 PM 收件者: Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>> 副本: Randy Liu <randyliu(a)pufsecurity.com<mailto:randyliu@pufsecurity.com>>; Victor Huang <victor(a)pufsecurity.com<mailto:victor@pufsecurity.com>>; Neil Chen <neilchen(a)pufsecurity.com<mailto:neilchen@pufsecurity.com>>; Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com<mailto:Shebu.VargheseKuriakose@arm.com>> 主旨: RE: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform HI Andy, Great to hear good news. I will be in annual leave from tomorrow, Aug 1st, but Antonio (coped) could help you and can redirect the possible questions to appropriate team members. With the occasion, I would appreciate if your team evaluates and follows TF-M documentation and gives us feedback on possible confusion or missing information. Best regards, Anton From: Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>> Sent: Wednesday, July 31, 2024 3:26 PM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: Randy Liu <randyliu(a)pufsecurity.com<mailto:randyliu@pufsecurity.com>>; Victor Huang <victor(a)pufsecurity.com<mailto:victor@pufsecurity.com>>; Neil Chen <neilchen(a)pufsecurity.com<mailto:neilchen@pufsecurity.com>> Subject: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform #Set a new mail loop Hi Anton, We set a kick-off meeting of "PSA Crypto API with PUFcc on the TF-M platform" this week. • TF-M v2.1.0 • PSA Crypto API - v1.2.1 • PSA Certified APIs Architecture Test Suite - v1.6 • MPS3 with AN552 Randy, Victor, and Neil are members of this project. We would have many issues when developing that need your help to solve it. Please feel free to add your teams. Let's make the project successful. Thank you very much. Have a Nice Day, Andy [cid:image001.png@01DAEFC5.FD4AE270] 熵碼科技股份有限公司 Tel: 886-3-5601010 #2119 Email: andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com> Website: https://www.pufsecurity.com/ -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- 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. -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------

10 months, 1 week

3
2
0 0

ARMCLANG generates ELF with armv3m architecture

by Roman.Mazurak＠infineon.com

Hello, We noticed that build of TF-M for CM33 platform generates ELF file for which architecture is armv3m. Step to reproduce: 1. Build TF-M secure image for CM33 platform with armclang (used 6.19). 2. Use arm-none-eabi-objdump provided with arm-gnu-toolchain-11.3.rel1-mingw-w64-i686-arm-none-eabi to print headers: * arm-none-eabi-objdump -x tfm_s.axf You will see following output: tfm_s.axf architecture: armv3m, flags 0x00000012: EXEC_P, HAS_SYMS While fromelf (from armclang) prints following: ======================================================================== ** ELF Header Information File Name: tfm_s.axf Machine class: ELFCLASS32 (32-bit) Data encoding: ELFDATA2LSB (Little endian) Header version: EV_CURRENT (Current version) Operating System ABI: none ABI Version: 0 File Type: ET_EXEC (Executable) (2) Machine: EM_ARM (ARM) Image Entry point: 0x16004319 Flags: EF_ARM_HASENTRY + EF_ARM_ABI_FLOAT_HARD (0x05000402) ARM ELF revision: 5 (ABI version 2) Is't expected? Because we have problems with debugging images generated by armclang in eclipse with gdb. Regards, Roman.

10 months, 1 week

2
1
0 0

Improved linker files supporting TF-M isolation L1-3

by Jamie Fox

Hi all, I have pushed for review a change to improve the TF-M linker scripts / scatter files: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/30316 There are two ideas behind the change: * Merge the isolation level 3 features from the tfm_isolation_l3 linker files into tfm_common_s, so that one linker file can support all TF-M isolation levels. * Group the memory by its desired memory protection attribute as far as possible, so that as much of the memory map as possible can be covered by MPU regions to restrict the attributes to no more than needed. The main advantage of this is to reduce how much of the memory is executable. There are more details in the commit message. Since it could be a disruptive change, the new linker files are added in addition to the existing tfm_common_s.sct/ld/icf and tfm_isolation_l3.sct/ld/icf ones and only platforms that are already using the common tfm_hal_isolation_v8m.c are switched over for now. But the idea is that platforms can gradually migrate and eventually the existing linker files can be removed. Kind regards, Jamie

10 months, 1 week

2
1
0 0

Integrate TF-M and PSA Crypto API with PUFcc

by Andy Chen

Hi TF-M teams, This is Andy from PUFsecurity, and we have a project with ARM. We try to integrate the PSA Crypto API with PUFcc (Our Crypto Engine) on TF-M. However, there are multiple versions included, and we need your assistance for specification clarification. Please ensure the versions match your recommendations. For TF-M, we plan to integrate with: TF-M v2.1.0 PSA Crypto API - v1.1.0 PSA Certified APIs Architecture Test Suite - v1.6 TF-M It would be beneficial to use the same hardware (FPGA) and tools as the ARM development team. If we can confirm which models are used for TF-M , scripts or details with the ARM hardware That would be grateful. PSA Crypto API - The test bench is using the PSA Crypto API v1.1.0, and it is published in 2022. And Now is v1.2.1 in March 2024. I not sure it is a good choose or not. [cid:983ad4d1-6d7d-4acb-a22d-5a49b94594d4] Test Bench - For the "PSA Certified APIs Architecture Test Suite - v1.6," we would like to identify which test codes (test_c001 to test_c067) are relevant for TF-M. Thank you very much!!! Have a Nice Day, Andy [cid:2fcb4633-c50b-4a64-8161-c5020f3b1ad3] 熵碼科技股份有限公司 Tel: 886-3-5601010 #2119 Email: andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com> Website: https://www.pufsecurity.com/ -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.-------- -------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------

11 months

2
1
0 0

Suggestion for unified logging library

by Jackson Cooper-Driver

Hi all, I would like to propose a unified logging library in TF-M. The primary aim of this is to combine the fragmented logging we have across TF-M into a single logging library, with a single top-level API. Currently, different components (BL1, SPM, secure partition, etc.) have different logging APIs and these also have different underlying implementations. Some call directly into the UART output string function and others call printf. Sometimes using one logging API in a different component leads to build failures, or nothing ending up on the UART at all. The primary aim here is for users to be able to use the same API throughout TF-M and for it to always work. This API will naturally be split into different logging levels, with build configuration controlled whether or not the string is actually output. Note that the underlying implementation can be different for different components - there can be hooks within the library which allow components to specify how they want to output the string. Initially, these can be used to maintain the existing underlying implementation. In the longer term, however, it would be useful to unify the underlying implementation also whether that be by using printf or with our own custom printf format parser. Please let me know any thoughts or concerns about the above suggestion. Thanks, Jackson

11 months, 2 weeks

1
0
0 0

User interview sign up and information

by Lisa Durbin

Hello everyone, Thank you for giving us the opportunity to understand more about you and how we can design the technical information for your needs. For those who weren’t on the technical forum call today, here’s a summary of what these interviews are about: We’re calling for volunteers to help us better understand who our users are and how we can improve your technical documentation journey. We’ll be conducting 45 minute – 1 hour interviews over Zoom to ask questions about your role, the tasks you perform, how you learn, and how you use our documentation. In today’s forum, Lisa Durbin (Principal Technical Content Developer) will run through the details about the interviews and how you can take part. If you’re interested in taking part in the interviews, please do both of the following: 1. Fill out the consent form here on the Microsoft Forms site<https://forms.office.com/Pages/ResponsePage.aspx?id=eVlO89lXqkqtTbEipmIYTWl…>. 2. Book a 1 hour Zoom session with me here on the Office Bookings site.<https://outlook.office.com/bookwithme/user/5b86408b60db4f51ba9459930fbc64a3…> Please note, I’m based in Cambridge UK and my availability is during BST office hours. I’ll be running the sessions starting July 8th until September 30th, 2024. If you have any questions or would like further information, please feel free to email me directly. Thank you again for your help. Kind regards, Lisa Durbin Lisa Durbin | Principal Technical Content Developer She/her CE-SW Technology Management team Cambridge

11 months, 3 weeks

1
0
0 0

RFC: Remove specific section for psa_interface_thread_fn_call

by Nicola Mazzucato

Hi All, I pushed for review a Request For Comments (RFC) patch where I remove specific attributes for sections introduced a while ago. At that time, it was fixing an issue with Armclang builds. However it has been noticed that with GCC, those functions are not placed within the .text section, as otherwise expected. With the proposed RFC patch https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/29755, I ran a few tests and builds and the "old" issue with Armclang does not appear anymore and the functions are correctly placed within the .text section. I would like to ask the community to cherry pick the patch and build & run their tests, to further verify that we are not breaking anything else. If no issues are reported in a week or so, I will remove the RFC and then the patch will go through the final review. Many thanks in advance for your cooperation. Best regards, 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.

11 months, 3 weeks

1
0
0 0

Question about random number g

by Zhang, Hao

Hi TF-M and mbedtls community, I am new to TF-M, I have a few questions about CryptoCell and random number generation. Thank you in advance. 1. I figure there seems to have two CryptoCell 312 implementations within TF-M. One under lib/ext/cryptocell-312-runtime and the other under platform/ext/accelerator/cc312/cc312-rom. What are the difference between these two? 2. For lib/ext/cryptocell-312-runtime, it does not define MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG whereas /ext/accelerator/cc312/cc312-rom does. Does that mean cryptocell-312-runtime is initiating RNG cryptodriver by using mbedtls_entropy_add_source whereas cc312-rom is using mbedtls_psa_external_get_random<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>. If so, may I ask why these two cryptocells take two different approaches? I read from one of the documentation that mbedtls_psa_external_get_random is used when entropy is sufficient. So if entropy is sufficient, is it always preferred to have MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG defined and implements mbedtls_psa_external_get_random? What are the differences between the two approaches. 3. I also found cryptocell-312-runtime defines the entry point function cc3xx_init_random<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>. But since PSA random number entry point funciton is not complete, the cc3xx_init_random is not being called anywhere, right? [https://opengraph.githubassets.com/17cdebc400b0ed807c620b586b21f3f77ff9c5d3…]<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…> trusted-firmware-m/platform/ext/accelerator/cc312/cc312-rom/psa_driver_api/src/cc3xx_psa_random.c at 8df9cc8baf46252fd188bba1d87333a8daa9a5e8 · zephyrproject-rtos/trusted-firmware-m<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…> Zephyr repository tracking https://git.trustedfirmware.org/trusted-firmware-m.git/ - zephyrproject-rtos/trusted-firmware-m github.com 4. I know random number generation PSA entry point function is in development, may I ask when that would be expected to complete? Thank you very much! Best regards, Hao

11 months, 3 weeks

2
2
0 0

Technical Forum call - July 7

by Anton Komlev

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

11 months, 3 weeks

10
62
0 0

New to TF-M

by Michael Khoyilar

Hi all I am porting a new SoC to TF-M platform. I know I have missed something in my platform files that I am getting following error message, can someone please guide me. Thanks Built target manifest_tool [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/uart_stdout.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/nv_counters.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/flash_otp_nv_counters_backend.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/otp_flash.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/provisioning.o [ 8%] Linking C static library libplatform_s.a [ 12%] Built target platform_s [ 13%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/service_api.o [ 13%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/spm/core/psa_interface_sfn.o [ 13%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_psa_call.o [ 14%] Linking C static library libtfm_sprt.a [ 17%] Built target tfm_sprt [ 17%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/tfm_boot_data.o [ 17%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/utilities.o [ 18%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/arch/tfm_arch.o [ 18%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/main.o [ 19%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/spm_ipc.o [ 19%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/rom_loader.o [ 20%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/psa_api.o [ 20%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/psa_call_api.o [ 20%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/psa_version_api.o [ 21%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/psa_read_write_skip_api.o [ 21%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/backend_sfn.o [ 23%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/tfm_svcalls.o [ 23%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/tfm_pools.o [ 24%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ns_client_ext/tfm_spm_ns_ctx.o [ 24%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/spm_local_connection.o [ 24%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/arch/tfm_arch_v8m_main.o [ 25%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/platform/ext/common/tfm_hal_nvic.o C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c: In function 'tfm_hal_irq_enable': C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:21:5: warning: implicit declaration of function 'NVIC_EnableIRQ' [-Wimplicit-function-declaration] 21 | NVIC_EnableIRQ((IRQn_Type)irq_num); | ^~~~~~~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:21:21: error: 'IRQn_Type' undeclared (first use in this function) 21 | NVIC_EnableIRQ((IRQn_Type)irq_num); | ^~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:21:21: note: each undeclared identifier is reported only once for each function it appears in C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:21:31: error: expected ')' before 'irq_num' 21 | NVIC_EnableIRQ((IRQn_Type)irq_num); | ~ ^~~~~~~ | ) C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c: In function 'tfm_hal_irq_disable': C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:28:5: warning: implicit declaration of function 'NVIC_DisableIRQ' [-Wimplicit-function-declaration] 28 | NVIC_DisableIRQ((IRQn_Type)irq_num); | ^~~~~~~~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:28:22: error: 'IRQn_Type' undeclared (first use in this function) 28 | NVIC_DisableIRQ((IRQn_Type)irq_num); | ^~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:28:32: error: expected ')' before 'irq_num' 28 | NVIC_DisableIRQ((IRQn_Type)irq_num); | ~ ^~~~~~~ | ) C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c: In function 'tfm_hal_irq_clear_pending': C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:35:5: warning: implicit declaration of function 'NVIC_ClearPendingIRQ' [-Wimplicit-function-declaration] 35 | NVIC_ClearPendingIRQ((IRQn_Type)irq_num); | ^~~~~~~~~~~~~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:35:27: error: 'IRQn_Type' undeclared (first use in this function) 35 | NVIC_ClearPendingIRQ((IRQn_Type)irq_num); | ^~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:35:37: error: expected ')' before 'irq_num' 35 | NVIC_ClearPendingIRQ((IRQn_Type)irq_num);

1 year

2
1
0 0

Re: Firmware Update: Storage Failure While Rejecting a Staged Image

by Cedric Klikpo

Hi Maulik, Thanks for your support. 1. I think I understand why you don’t get the error on the Musca-B1. In fact, we are not using the same flash driver: 1.1. My build uses the `emulated_flash_dvr`, which checks that the byte is erased in flash before attempting a write (this is where I get the error). 1.2. The Musca-B1 platform uses the `qspi_ip6514e_drv`, which does not perform such a check before writing to the flash. From what I understand, the MT25QL Series Flash NOR does not return an error even if you try to write a 1 in a bit that was 0. As such, you do not encounter the error. 2. It is strange that you don’t get the warning when MCUBOOT_CONFIRM_IMAGE=OFF. Best regards, Cédric

1 year

1
0
0 0

Re: Firmware Update: Storage Failure While Rejecting a Staged Image

by Maulik Patel

Hello Cedric, I built with both MCUBOOT_CONFIRM_IMAGE=OFF (default config for musca b1) and MCUBOOT_CONFIRM_IMAGE=ON and in both cases, I do not get any error/warning. Running Test Suite PSA firmware update NS interface tests (TFM_NS_FWU_TEST_1xxx)... > Executing 'TFM_NS_FWU_TEST_1001' Description: 'Functionity test.' TEST: TFM_NS_FWU_TEST_1001 - PASSED! > Executing 'TFM_NS_FWU_TEST_1002' ... Best Regards, Maulik ________________________________ From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org> Sent: 13 June 2024 1:00 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Digest, Vol 68, Issue 13 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Re: Firmware Update: Storage Failure While Rejecting a Staged Image (cedric.klikpo(a)scalinx.com) ---------------------------------------------------------------------- Message: 1 Date: Wed, 12 Jun 2024 14:06:16 -0000 From: cedric.klikpo(a)scalinx.com Subject: [TF-M] Re: Firmware Update: Storage Failure While Rejecting a Staged Image To: tf-m(a)lists.trustedfirmware.org Message-ID: <171820117605.1175.3411332003376446357(a)lists.trustedfirmware.org> Content-Type: text/plain; charset="utf-8" Hi Maulik, Sorry, I forgot to mention that I got the error when the image is built with the option "MCUBOOT_CONFIRM_IMAGE" enabled. When, when this option is not enable, I do not get the error, and the FWU test status is PASSED. However, the test is marked as passed with the following warning, which clearly states that the testcase is skipped: ``` Executing 'TFM_NS_FWU_TEST_1001' Description: 'Functionality test.' The component isn't in READY state: the device is not ready to run FWU tests, skip FWU test: 1. TEST: TFM_NS_FWU_TEST_1001 - PASSED! ``` So, I would like to confirm with you: 1. When you enable the option "MCUBOOT_CONFIRM_IMAGE," does your TFM_NS_FWU_TEST_1001 testcase pass? 2. When you disable the option "MCUBOOT_CONFIRM_IMAGE," do you get the same warning? Best regards, Cédric ------------------------------ Subject: Digest Footer TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org ------------------------------ End of TF-M Digest, Vol 68, Issue 13 ************************************

1 year

1
0
0 0

Re: Firmware Update: Storage Failure While Rejecting a Staged Image

by Maulik Patel

Hello Cedric Unfortunately we only have musca b1 support for FWU at the moment. However as you mentioned, I did try TFM version 1.8.0 on commit *35ac80c85 and all tests (secure and non-secure including FWU) passes without any issues. Best Regards, Maulik

1 year

2
1
0 0

Re: Firmware Update: Storage Failure While Rejecting a Staged Image

by Maulik Patel

Hello Cedric, I tried the FWU tests on musca b1 platform and all of them passes without any failures. Could you please provide more context on specific version/commit or platform where you encounter PSA_ERROR_STORAGE_FAILURE? Best Regards, Maulik ________________________________ From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org> Sent: 07 June 2024 1:00 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Digest, Vol 68, Issue 6 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Firmware Update: Storage Failure While Rejecting a Staged Image (cedric.klikpo(a)scalinx.com) ---------------------------------------------------------------------- Message: 1 Date: Thu, 06 Jun 2024 13:00:29 -0000 From: cedric.klikpo(a)scalinx.com Subject: [TF-M] Firmware Update: Storage Failure While Rejecting a Staged Image To: tf-m(a)lists.trustedfirmware.org Message-ID: <171767882935.438215.6657950002748011855(a)lists.trustedfirmware.org> Content-Type: text/plain; charset="utf-8" Hi, I encounter a storage failure when trying to reject a staged image. I get this error by executing `tfm_fwu_test_common_001` in `fwu_tests_common.c`. The error occurs when the `erase_boot_magic` function attempts to erase the magic number in the image trailer by writing erase into it. The reason I am writing this post is to ask: 1. If the `erase_boot_magic` failure is a known bug in the firmware update, is a fix planned or existing? 2. Why doesn't the `erase_boot_magic` function erase the sector where the magic number is located in the image trailer, considering we erasing in a flash? Thanks! Best regards, Cedric ------------------------------ Subject: Digest Footer TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org ------------------------------ End of TF-M Digest, Vol 68, Issue 6 ***********************************

1 year

2
1
0 0

API_DISPATCH for tfm_crypto_api.c

by Quach, Brian

Hi, I noticed that trusted-firmware-m\interface\src\tfm_crypto_api.c defines two API_DISPATCH macros for psa_call(). It is used most of the time in the file, but I still see ~10 instances where psa_call() is used. Can it be changed to consistently use the API_DISPATCH macros. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

1 year

2
2
0 0

PSA Cryptoprocessor Driver Interface

by Zhang, Hao

Hi TF-M community, TF-M allows Semiconductor vendors to plug in their HW accelerator using PSA cryptoprocessor driver interface. I have a couple of questions in terms of the driver interface. 1. To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS using driver interface, for the multipart operation, https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa… states that "A driver that implements a multi-part operation must define all of the entry points in this family as well as a type that represents the operation context." Take aead encrypt as an example, if the underlying hardware does not support aead_abort, could it implements aead_abort by simply return PSA_ERROR_NOT_SUPPORTED? 2. The driver interface depends heavily on psa_crypto_driver_wrappers.h to dispatch operations to customized HW accelerator, where the psa_crypto_driver_wrappers.h file is automatically generated by scripts/data_files/driver_templates/psa_crypto_driver_wrappers.h.jinja. To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS, would the approach be creating a customized psa_crypto_driver_wrappers.h.jinja file, the driver description file in JSON, and entry point functions. If so and we are considering upstreaming TF-M in the future, all these files would go inside platform/ext/accelerator/<vendor name>. Efforts need to be made so files such as psa_crypto_driver_wrappers.h.jinja should point to mbedtls, right? Additionally, as .jinja is retiring (mentioned in another email exchange), how would semi vendors update psa_crypto_driver_wrappers.h in the future? [https://opengraph.githubassets.com/c87e79773a7fb0841ea038f7cf3dfdf4170debb8…]<https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa…> mbedtls/docs/proposed/psa-driver-interface.md at zephyr · zephyrproject-rtos/mbedtls<https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa…> mbedtls module for Zephyr, this is not a mirror of the official mbedtls repository. - zephyrproject-rtos/mbedtls github.com Thank you very much! Best regards

1 year

4
9
0 0

Firmware Update: Storage Failure While Rejecting a Staged Image

by cedric.klikpo＠scalinx.com

Hi, I encounter a storage failure when trying to reject a staged image. I get this error by executing `tfm_fwu_test_common_001` in `fwu_tests_common.c`. The error occurs when the `erase_boot_magic` function attempts to erase the magic number in the image trailer by writing erase into it. The reason I am writing this post is to ask: 1. If the `erase_boot_magic` failure is a known bug in the firmware update, is a fix planned or existing? 2. Why doesn't the `erase_boot_magic` function erase the sector where the magic number is located in the image trailer, considering we erasing in a flash? Thanks! Best regards, Cedric

1 year

1
0
0 0

Remove 'tfm_api_ns_tz' and 'tfm_api_ns_mailbox' targets

by Anton Komlev

Hello, I want to bring community attention to a bug fix in build script for NS application: In the original design we shall have a single CMake target 'tfm_api_ns' prepared and exported by SPE for building NSPE with consistent configuration. At some moment 2 extra targets 'tfm_api_ns_tz' and 'tfm_api_ns_mailbox' were introduced for different S-NS communication methods to be linked to tfm_api_ns on NS side. This created unnecessary NS dependency on SPE configuration and disallows creating NS application working with all platforms. This patch is fixing the issue: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/29005 Ideally, we should remove these redundant targets but that will break projects already adjusted and using them. There are 2 approaches to address the issue: 1. Preferred. Remove the targets and ask dependent projects for adjustment. (effectively, is 1 line change to stop linking to them). 2. Keep those targets as empty dummies for compatibility, polluting the code. Please comment and object the removal (approach 1) if it's critical for your project. I would appreciate your feedback within 2 weeks to make the right decision. Thanks, Anton

1 year

1
0
0 0

help - error in regression.sh using STM Nucleo-L552ZE-Q

by Miguel Costa

Hello, I followed this tutorial to add an example secure partition in TF-M ( https://tf-m-user-guide.trustedfirmware.org/integration_guide/services/tfm_… ) and then followed these instructions to flash the application to my Nucleo-L552ZE-Q board ( https://tf-m-user-guide.trustedfirmware.org/platform/stm/common/stm32l5xx/r… ). However, the script regression.sh returned the error: Error: Cannot connect to access port 0! If you are trying to connect to a device with TrustZone enabled please try to connect with HotPlug mode. If you are trying to connect to a device which supports Debug Authentication with certificate or password, please open your device using it. After this, I am unable to connect my board STM32Cube Programmer or to flash any application using Keil MDK ARM, CubeIDE, etc. The same error is returned every time. Before I runned the regression.sh script, the board was working as expected and I was able to flash simple applications (non using TF-M) to the board. I've already tried to connect the board to the STM32Cube Programmer using the Hot Plug mode - (i) pulled BOOT0 pin to HIGH, (ii) connected the board to the PC, (iii) selected Hot Plug mode in STM32Cube Programmer and Hit Connect - but did not work. I get this log: [cid:20937ade-7ed2-4beb-bced-d577c3e58dd3]

1 year, 1 month

1
0
0 0

psa_interface_thread_fn_call section

by Bohdan.Hunko＠infineon.com

Hi all, Why does TFM assigns function to psa_interface_thread_fn_call section and then never places them anywhere specific? This way functions assigned to this section are placed outside of the code region which may result in unpredictable behavior. 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 year, 1 month

2
4
0 0

Re: Is cryptocell-312 now maintaining by TF-M mainly?

by Lee, William

Thanks Antonio! 😊 (fixed typo in subject, sorry ☹) Thanks, William From: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> Date: Wednesday, May 15, 2024 at 2:18 PM To: "Lee, William" <William.Lee(a)garmin.com>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: Re: Is crytocell-312 now maintaining by TF-M mainly? Yes, CryptoCell code in the TF-M repo is the only maintained repository. Thanks, Antonio Sent from Outlook for Android From: Lee, William via TF-M <tf-m@ lists. trustedfirmware. org> Sent: Wednesday, May 15, 2024 5: 32: 59 am To: tf-m@ lists. trustedfirmware. org Yes, CryptoCell code in the TF-M repo is the only maintained repository. Thanks, Antonio Sent from Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/AAb9ysg__;!!EJc4YC3iFmQ!Q29CY2id1…> ________________________________ From: Lee, William via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, May 15, 2024 5:32:59 am To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Is crytocell-312 now maintaining by TF-M mainly? Hello! I saw [1] is not updating anymore, but [2] is still active, anyone knows if [2] is the main place for cryptocell-312? Thanks! [1] https://github.com/ARM-software/cryptocell-312-runtime<https://urldefense.com/v3/__https:/github.com/ARM-software/cryptocell-312-r…> [2] https://git.trustedfirmware.org/TF-M/trusted-firmware-m/+log/refs/heads/mai…<https://urldefense.com/v3/__https:/git.trustedfirmware.org/TF-M/trusted-fir…> Thanks, William

1 year, 1 month

2
1
0 0

Is crytocell-312 now maintaining by TF-M mainly?

by Lee, William

Hello! I saw [1] is not updating anymore, but [2] is still active, anyone knows if [2] is the main place for cryptocell-312? Thanks! [1] https://github.com/ARM-software/cryptocell-312-runtime [2] https://git.trustedfirmware.org/TF-M/trusted-firmware-m/+log/refs/heads/mai… Thanks, William

1 year, 1 month

2
1
0 0

TF-M release v2.1.0 announcement

by Anton Komlev

Hello, I am happy to announce the new release of TF-M v2.1.0. New major features are: * TF-M aligns the Crypto service to the same PSA Crypto headers used by the Mbed TLS 3.6.0 reference implementation. * Initial support for on-core and off-core clients on Hybrid platforms (A-profile + M-profile or M-profile + M-profile) using solution 1. The functionality is still under active development. * P256-M component is enabled on the BL2 stage for image signature verification based on ECDSA. * MCUboot upgrade to v2.1.0. * Mbed TLS upgrade to v3.6.0. * BL2 now provides a thin PSA Crypto core layer when MCUBOOT_USE_PSA_CRYPTO=ON and can use builtin keys when ECDSA based signature verification is selected with MCUBOOT_SIGNATURE_TYPE="EC-P256". This version is the first, intended for Long Term Support (LTS) after PSA certification and tagging TF-Mv2.1.0-LTS as described in the updated Release Process. Please check the release notes for more information. The release branch changes will be ported to the main branch shortly. Many thanks to everyone for contributing, reviewing and supporting this milestone. Anton and TF-M team.

1 year, 1 month

1
0
0 0

Wrong Life Cycle values in iatverifier

by Bohdan.Hunko＠infineon.com

Hi I am trying to use iatverifier tool from tf-m-tools repo to verify token and it seems like the values for Security Lificycle in the tool are wrong, because: this spec https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-21.html defines them as psa-lifecycle-unknown-type = 0x0000..0x00ff psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff psa-lifecycle-secured-type = 0x3000..0x30ff psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff psa-lifecycle-decommissioned-type = 0x6000..0x60ff Which is consistent with values of tfm_security_lifecycle_t enum in TFM enum tfm_security_lifecycle_t { TFM_SLC_UNKNOWN = 0x0000u, TFM_SLC_ASSEMBLY_AND_TEST = 0x1000u, TFM_SLC_PSA_ROT_PROVISIONING = 0x2000u, TFM_SLC_SECURED = 0x3000u, TFM_SLC_NON_PSA_ROT_DEBUG = 0x4000u, TFM_SLC_RECOVERABLE_PSA_ROT_DEBUG = 0x5000u, TFM_SLC_DECOMMISSIONED = 0x6000u, TFM_SLC_MAX_VALUE = UINT32_MAX, }; But in the tf-m-tools/iat-verifier/iatverifier/psa_iot_profile1_token_claims.py these values are defined differently # Security Lifecycle claims SL_UNKNOWN = 0x1000 SL_PSA_ROT_PROVISIONING = 0x2000 SL_SECURED = 0x3000 SL_NON_PSA_ROT_DEBUG = 0x4000 SL_RECOVERABLE_PSA_ROT_DEBUG = 0x5000 SL_PSA_LIFECYCLE_DECOMMISSIONED = 0x6000 Thus I am getting SL_UNKNOWN instead of TFM_SLC_ASSEMBLY_AND_TEST Is this a known issue? Can this be fixed? 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 year, 1 month

3
3
0 0

Isolation Level 2/3 IO vector access

by Quach, Brian

Hi, For Isolation Level 2, ARoT cannot access PRoT data. If PRoT partition makes a call to ARoT partition, how are the input/output buffers made accessible to the ARoT partition so a transient copy of the data can be made? I looked at the AN521 implementation of tfm_hal_activate_boundary() and it does add any MPU regions to allow unprivileged access under Isolation Level 2. For Isolation Level 3, I assume the input/output buffers would need to added to a runtime memory asset to allow unprivileged access. Is my understanding correct? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 1 month

2
1
0 0

psa_unmap_invec

by Quach, Brian

Hi, I see that tfm_crypto_call_srv() unmaps output vectors if PSA_FRAMEWORK_HAS_MM_IOVEC == 1, but I never see psa_unmap_invec called. This doesn't seem to be required from a functional standpoint but I was wondering if psa_unmap_invec() was purposely skipped to save some unnecessary execution time. Is psa_unmap_invec() only implemented for testing purposes? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 1 month

2
1
0 0

build warning with PSA_FRAMEWORK_HAS_MM_IOVEC

by Quach, Brian

Hi, I noticed this build warning with PSA_FRAMEWORK_HAS_MM_IOVEC enabled. runtime_defs.h need to be updated to add the `const` qualifier I think. tfm/secure_fw/spm/core/psa_interface_thread_fn_call.c:287:33: warning: initialization of 'void * (*)(psa_handle_t, uint32_t)' {aka 'void * (*)(long int, long unsigned int)'} from incompatible pointer type 'const void * (*)(psa_handle_t, uint32_t)' {aka 'const void * (*)(long int, long unsigned int)'} [-Wincompatible-pointer-types] 287 | psa_map_invec_thread_fn_call, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /tfm/secure_fw/spm/core/psa_interface_thread_fn_call.c:287:33: note: (near initialization for 'psa_api_thread_fn_call.psa_map_invec') Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

1 year, 1 month

2
2
0 0

Start of TF-M v2.1.0 release

by Anton Komlev

Hi, We are starting the new TF-M release process on the branch release/2.1.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/+/refs/heads/re…> process and freezing the project features in it. RC1 tag will follow shortly. 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

1 year, 1 month

1
1
0 0

TF-M OpenCI issue in lava_test

by Anton Komlev

Hello, TF-M OpenCI fails all LAVA tests and all builds are fail consequently, probably because of a new license mechanism. An investigation and problem fixing are ongoing. I will update you when the problem will be resolved. Best regards, Anton

1 year, 2 months

1
1
0 0

Security Vulnerability Notice - Partial tag comparison when using Chacha20-Poly1305 on the PSA driver API interface in CryptoCell enabled platforms

by Antonio De Angelis

Hi Everyone, There is a new security vulnerability discovered on the PSA Driver API for CryptoCell enabled platforms, described as "Partial tag comparison when using Chacha20-Poly1305 on the PSA driver API interface in CryptoCell enabled platforms". Please find the security advisory specific to TF-M and patches that have been developed as per the TrustedFirmware.org security process [1] below : * TF-M Security advisory: TFMV-6: Add cc3xx_partial_tag_compare_on_chacha20_poly1305 advisory (I44bc426f) · Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/22995> * Patch to fix the issue has been already merged on master branch as commit https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=2e82… * TF-Mv1.8.1 will be released in the next days containing the same hotfix Please let us know if you have any comments. Best regards, /Antonio [1] https://developer.trustedfirmware.org/w/collaboration/security_center/report...<https://developer.trustedfirmware.org/w/collaboration/security_center/repor…>

1 year, 2 months

2
1
0 0

Re: Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file

by Antonio De Angelis

Hi Ruchika, thanks for your email and apologies for the late reply but I did not receive this directly so I am replying only because I was pointed to this. TF-M would really welcome a contribution to move those drivers to the autogen framework. This has not been done yet due to lack of bandwidth on TF-M side. Would like to note that the TF-M builtin key loader driver can't be (maybe, just completely) moved to the autogen framework because it patches some internals of Mbed TLS as well (i.e. you would need to patch the jinja template as well). But the CC3XX driver is absolutely something that we would like to move to the autogen framework without any issue. Thanks, Antonio

1 year, 2 months

2
1
0 0

Upcoming TF-M release heads up.

by Anton Komlev

Hello, We plan to initiate TF-M v2.1.0 release with a feature freeze on April 8th targeting completion before April 28th. Please let me know if there are pending patches critical to be included in this release and shall be merged before the feature freeze. Thanks, Anton

1 year, 2 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M