May 2025 - TF-M - lists.trustedfirmware.org

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

1 week, 1 day

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

3 months

2
2
0 0

Technical Forum call - Sep 12 (East time zone).

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, Sep 12 at 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 months, 1 week

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

9 months

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

10 months, 1 week

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

11 months, 2 weeks

1
2
0 0

Issue building docs

by Bohdan.Hunko＠infineon.com

Hi all, I am trying to build docs with following commands: cmake -S docs -B ./build_docs cmake --build build_docs/ -- tfm_docs_userguide_pdf But I get following error resolving references... failed Warning, treated as error: RSVG converter command 'rsvg-convert' cannot be run. Check the rsvg_converter_bin setting When I remove -W (warnings are errors) option from COMMAND "${SPHINX_EXECUTABLE}" -W -b html -j 1 -c ${SPHINXCFG_CONFIG_PATH} ${SPHINXCFG_SOURCE_PATH} "${SPHINXCFG_OUTPUT_PATH}/html" In docs/CMakeLists.txt then docs builds fine. Is this -W option intentional? Should this issue be fixed or -W removed? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

11 months, 2 weeks

2
2
0 0

PSA_IOT_PROFILE_1 attestation Certification Reference

by Quach, Brian

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

11 months, 4 weeks

3
3
0 0

Internal Trusted Storage

by Michael Khoyilar

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

12 months

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 year

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M May 2025