TF-M July 2025

tf-m@lists.trustedfirmware.org

9 participants
8 discussions

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

3 days, 3 hours

Issue with integrity_checker_compute_value() and cache coherence on RDV3R1 with TF-M

by 박진국

Hello, I am currently developing TF-M on the RDV3R1 S/W platform, and I would like to report a potential issue observed during runtime with the integrity_checker_compute_value() function in BL2. Problem Description: Inside the integrity_checker_compute_value() function, the iccva register is set to the address of either the value or temp_val variable, as shown in the example below. enum integrity_checker_error_t integrity_checker_compute_value(struct integrity_checker_dev_t *dev, enum integrity_checker_mode_t mode, const uint32_t *data, size_t size, uint32_t *value, size_t value_size, size_t *value_len) { volatile uint32_t __ALIGNED(INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) temp_val[INTEGRITY_CHECKER_OUTPUT_SIZE_SHA256 / sizeof(uint32_t)] = {0}; volatile uint32_t *value_ptr = value; struct _integrity_checker_reg_map_t* p_integrity_checker = (struct _integrity_checker_reg_map_t*)dev->cfg->base; enum integrity_checker_error_t err; uint32_t iccval = 0; err = check_mode_is_supported(dev, mode, true); if (err != INTEGRITY_CHECKER_ERROR_NONE) { return err; } if (value_size < mode_sizes[mode]) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_BUFFER_TOO_SMALL; } if (((uintptr_t)data % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_ALIGNMENT; } if ((size % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_INVALID_LENGTH; } if (((uintptr_t)value % INTEGRITY_CHECKER_REQUIRED_ALIGNMENT) != 0) { value_ptr = temp_val; } init_integrity_checker(dev, &iccval); /* Set algorithm */ iccval |= (mode & 0b111) << 1; /* Set to compute mode */ iccval |= 1 << 4; /* Configure input data. Size is in words */ p_integrity_checker->icda = remap_addr(dev, (uintptr_t)data); p_integrity_checker->icdl = size / INTEGRITY_CHECKER_REQUIRED_ALIGNMENT; /* Set output address */ p_integrity_checker->iccva = remap_addr(dev, (uintptr_t)value_ptr); /* Start integrity checker */ iccval |= 1; p_integrity_checker->icc = iccval; /* Poll for any interrupts */ while(!p_integrity_checker->icis) {} /* Check for any unusual error interrupts */ if (p_integrity_checker->icis & (~0b11)) { FATAL_ERR(INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED); return INTEGRITY_CHECKER_ERROR_COMPUTE_VALUE_OPERATION_FAILED; } if (value_ptr != value) { for (int idx = 0; idx < mode_sizes[mode] / sizeof(uint32_t); idx++) { value[idx] = value_ptr[idx]; } } if (value_len != NULL) { *value_len = mode_sizes[mode]; } return INTEGRITY_CHECKER_ERROR_NONE; } static void init_integrity_checker(struct integrity_checker_dev_t *dev, uint32_t *iccval) { struct _integrity_checker_reg_map_t* p_integrity_checker = (struct _integrity_checker_reg_map_t*)dev->cfg->base; /* Set MatchTriggerDisable, as it is mandatory. */ *iccval |= 1 << 5; /* Set EncompvalOut so the integrity checker writes the value pointer in * compute mode. */ *iccval |= 1 << 6; *iccval |= (IC_APROT_SECURE_PRIVILEGED & 0b11) << 7; *iccval |= (IC_APROT_SECURE_PRIVILEGED & 0b11) << 9; /* Disable all alarms */ p_integrity_checker->icae = 0; /* Enable and clear all interrupts */ p_integrity_checker->icie = 0xFF; p_integrity_checker->icic = 0xFF; } The issue arises because the memory areas pointed to by value and temp_val are cacheable (e.g., located in the vm0 memory region, which is configured as cacheable). As a result, even though the integrity checker writes the output data to the physical address of value or temp_val, the CPU cache is not updated, and this leads to stale data being read later in software, resulting in runtime errors. Expected Behavior: Ideally, the memory region used for integrity checker output should either be: Non-cacheable, or Explicitly synchronized (e.g., cache invalidated or cleaned) after the integrity checker operation. Could you please confirm whether this is a known issue, and advise on the recommended way to handle integrity checker outputs with respect to cache settings? Thank you. JK Park

4 days, 23 hours

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 days, 20 hours

TF-M BL2 compiling issue using RDINFRA

by 김태훈

Hello, I'm a RSE firmware developer for Arm Neoverse V3 core. I tried to build with argument MCUBOOT_ENC_IMAGES, MCUBOOT_ENCRYPT_RSA, and MCUBOOT_USE_PSA_CRYPTO for RSE PE encryption. In this process, I encountered an error during build TF-M using the repo for tag:RD-INFRA-2025.07.03. It seems that linking problem, and I found out that the error occurred while configuring BL2. However, that's all. Can anyone help me? Below log is in my terminal output.  p.s. If I reached wrong site, please forgive me and teach me a right one. cmake --build build --target bl2 [  0%] Built target manifest_tool [  0%] Built target bl2_scatter [ 10%] Built target bl2_cc3xx_psa_driver_api [ 31%] Built target bl2_cc3xx [ 68%] Built target platform_bl2 [ 78%] Built target bl2_crypto [ 94%] Built target bootutil [ 94%] Linking C executable ../bin/bl2.axf /home/gth1919/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: ext/mcuboot/bootutil/libbootutil.a(encrypted.o): in function `bootutil_rsa_oaep_decrypt': /TF_M/build/lib/ext/mcuboot-src/boot/bootutil/include/bootutil/crypto/rsa.h:107: undefined reference to `psa_asymmetric_decrypt' Memory region         Used Size  Region Size  %age Used            FLASH:       80356 B       126 KB     62.28%              RAM:       35360 B       896 KB      3.85% collect2: error: ld returned 1 exit status gmake[3]: *** [bl2/CMakeFiles/bl2.dir/build.make:222: bin/bl2.axf] Error 1 gmake[2]: *** [CMakeFiles/Makefile2:2661: bl2/CMakeFiles/bl2.dir/all] Error 2 gmake[1]: *** [CMakeFiles/Makefile2:2668: bl2/CMakeFiles/bl2.dir/rule] Error 2 gmake: *** [Makefile:520: bl2] Error 2 HP. Mail.  010-6768-7791  gth1919(a)adtek.co.kr Application Platform Group김태훈 연구원 (주)에이디테크놀로지 (16512) 경기도 수원시 영통구 광교중앙로248번길 7-8 Web. http://www.adtek.co.kr

1 week, 2 days

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

Trusted Firmware Gerrit issues

by Matthew Dalzell

Hi All, We have recently undergone a migration of our Gerrit server and are seeing some issues. One such change appears to be that https://review.trustedfirmware.org/TF-M/trusted-firmware-m no longer resolves to https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m. So please use the latter link if that is what you wish to access. This is causing a large slow-down on the CI causing jobs to not be run. These issues are being actively worked on and we hope all will be back up and running normally soon. If you have any questions or related issues please feel free to respond to this chain. Thank you for your patience, Matt

2 weeks, 4 days

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

Iar Linker duplicate file

by Inhelder Nicolas

Hi When compiling with IAR bxarm 9.7.1 i get the following linker errors: cmake -S . -B cmake_build -DTFM_PLATFORM=arm/mps2/an521 -DTFM_TOOLCHAIN_FILE=toolchain_IARARM.cmake cmake --build cmake_build -- install [25/31] Linking C executable bin/tfm_s.axf Warning[Li065]: duplicate file: "/home/ubuntu/import/source/trusted-firmware-m/ cmake_build/platform/libplatform_s.a" Warning[Li065]: duplicate file: "/home/ubuntu/import/source/trusted-firmware-m/ cmake_build/secure_fw/partitions/lib/runtime/libtfm_sprt.a" Warning[Li065]: duplicate file: "/home/ubuntu/import/source/trusted-firmware-m/ cmake_build/secure_fw/spm/libtfm_spm.a" In the build.ninja file you can see that all those libraries are includes twice. LINK_LIBRARIES = platform/libplatform_s.a secure_fw/partitions/lib/runtime/libtfm_sprt.a secure_fw/spm/libtfm_spm.a secure_fw/partitions/internal_trusted_storage/libtfm_psa_rot_partition_its.a secure_fw/partitions/platform/libtfm_psa_rot_partition_platform.a platform/libplatform_s.a secure_fw/partitions/lib/runtime/libtfm_sprt.a secure_fw/spm/libtfm_spm.a secure_fw/partitions/internal_trusted_storage/libtfm_psa_rot_partition_its.a secure_fw/partitions/platform/libtfm_psa_rot_partition_platform.a Is there a reason this is not resolved or this just the way Cmake works? Is there an easy way to resolve this on the platform level? I used the an521 as a template to create my platform. In my platform this list grows with every feature I activate: Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/platform/libplatform_s.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/lib/runtime/libtfm_sprt.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/spm/libtfm_spm.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/platform/libplatform_crypto_keys.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/crypto/mbedcrypto/library/libmbedcrypto.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/crypto/libtfm_psa_rot_partition_crypto.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/internal_trusted_storage/libtfm_psa_rot_partit ion_its.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/platform/libtfm_psa_rot_partition_platform.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/firmware_update/libtfm_psa_rot_partition_fwu.a " Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/lib/runtime/libtfm_sp_log.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/platform/libplatform_s.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/lib/runtime/libtfm_sprt.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/spm/libtfm_spm.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/platform/libplatform_crypto_keys.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/crypto/mbedcrypto/library/libmbedcrypto.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/crypto/libtfm_psa_rot_partition_crypto.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/internal_trusted_storage/libtfm_psa_rot_partit ion_its.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/platform/libtfm_psa_rot_partition_platform.a" Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/firmware_update/libtfm_psa_rot_partition_fwu.a " Warning[Li065]: duplicate file: "/home/source/trusted-firmware-m/cmake_buil d/secure_fw/partitions/lib/runtime/libtfm_sp_log.a" If possible, I want to build without warnings. Thanks for your help Kind regards, Nico

2 weeks, 5 days

2025

2024

2023

2022

2021

2020

2019

2018

TF-M July 2025