- TF-M - lists.trustedfirmware.org

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

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

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

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

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

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

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

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

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M