- TF-M - lists.trustedfirmware.org

How to solve the link error while enable both mbedTLS and TF-M crypto interfaces in NSPE

by Edward Yang

Hi experts, Recently we're developing an example demo based on TF-M, the application scenario is simplified as below. MbedTLS module in NSPE is used to guarantee the secure communication with AWS cloud, while TF-M in SPE provides data encryption/decryption and sensitive data storage services. So both TF-M interfaces and mbedtls module are enabled on NSPE, there will be two implementations of PSA Crypto and this will result in a link error. The red box displays files with conflicts between mbedtls and TF-M, which prevent the project from compiling. Can all TF-M code be converted into a lib to avoid linking issues? Or is there any other way to solve this problem? Best Regards, Poppy Wu http://www.mxic.com.cn

3 years, 6 months

5
6
0 0

Re: [tfm_test_repo]why should the sha_1 not be supported at secure test suite

by zhilei.wang＠bekencorp.com

Hi, Antonio, Get it. Thank you very much Best Regards zhilei.wang | bekencorp From: Antonio De Angelis via TF-M Date: 2023-05-11 20:35 To: tf-m CC: nd Subject: [TF-M] Re: [tfm_test_repo]why should the sha_1 not be supported at secure test suite Hi Zhilei, The configuration of the TF-M Crypto service that it’s tested by default is just an example, and the SHA-1 algorithm is allowed from the PSA spec point of view; in our case we have decided to not enable SHA-1 support due to the fact that it’s widely accepted to have known collision attacks [1], NIST deprecating it in 2011 [2], and having exposed weaknesses since long, 2005 [3], i.e. to encourage by default having a look into more robust alternatives. Anyway, TF-M’s test 1010 just aims at testing the interface for the correct error response, nothing more. If your deployment still supports PSA_ALG_SHA_1, I’d recommend to just ignore the output of TEST_1010. On our side, we could gate the test not to run when PSA_WANT_ALG_SHA_1 is defined. Thanks, Antonio [1] SHAttered [2] NIST Retires SHA-1 Cryptographic Algorithm | NIST [3] 010.pdf (iacr.org) From: zhilei.wang(a)bekencorp.com <zhilei.wang(a)bekencorp.com> Sent: Thursday, May 11, 2023 13:44 To: tf-m <tf-m(a)lists.trustedfirmware.org> Cc: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; Summer Qin <Summer.Qin(a)arm.com>; poppywu <poppywu(a)mxic.com.cn> Subject: [tfm_test_repo]why should the sha_1 not be supported at secure test suite Hi, Why should the sha_1 not be supported at secure test suite? Our soc has a cypto accelerator, that supports sha_1/224 and so on. The following is the detail. File: \tfm\lib\ext\tfm_test_repo-src\test\secure_fw\suites\crypto\secure\crypto_sec_interface_testsuite.c Function: static void tfm_crypto_test_1010(struct test_result_t *ret) { psa_unsupported_hash_test(PSA_ALG_SHA_1, ret); } Thanks and best regards, zhilei.wang bekencorp

3 years, 6 months

1
0
0 0

[tfm_test_repo]why should the sha_1 not be supported at secure test suite

by zhilei.wang＠bekencorp.com

Hi, Why should the sha_1 not be supported at secure test suite? Our soc has a cypto accelerator, that supports sha_1/224 and so on. The following is the detail. File: \tfm\lib\ext\tfm_test_repo-src\test\secure_fw\suites\crypto\secure\crypto_sec_interface_testsuite.c Function: static void tfm_crypto_test_1010(struct test_result_t *ret) { psa_unsupported_hash_test(PSA_ALG_SHA_1, ret); } Thanks and best regards, zhilei.wang bekencorp

3 years, 6 months

2
1
0 0

TF-M Confidential AI presentation next tech forum?

by Kevin Townsend

Hi, I'd like to propose presenting some of the work we've done around "Confidential AI" with TF-M and Zephyr during the next TF Tech Forum call. I think I'll probably need 30 minutes or so, and can take some questions after time and agenda permitting. If you're not familiar with the project, it's an attempt at trying to determine how open standards and open source software (Zephyr, TF-M, MCUBoot, etc.) can be used together in a practical, end-to-end security use case ... in this case, running inference on sensor data in the secure partition, and transmitting sensitive data from S to NS to the cloud. Relevant repos are here, but of course I'll try to give a meaningful overview of all of this during the call since the project has several related components: - https://github.com/Linaro/zephyr_confidential_ai - https://github.com/Linaro/lite_bootstrap_server Thanks and best regards, Kevin Townsend Tech Lead - LITE, Vertical Technologies Linaro.org │ Open source software for ARM SoCs

3 years, 6 months

1
0
0 0

SP FPU config

by Quach, Brian

Hi, Is it correct that CONFIG_TFM_FP_ARCH_ASM is 'empty string' when using FP_ARCH_FPV5_SP_D16? I'm wondering if it should be set to "FPv5-SP" ############################## FP Arch ######################################### config FP_ARCH_FPV5_D16 def_bool n help FPv5-D16 config FP_ARCH_FPV5_SP_D16 def_bool n help FPv5-SP-D16 config CONFIG_TFM_FP_ARCH string default "fpv5-d16" if FP_ARCH_FPV5_D16 default "fpv5-sp-d16" if FP_ARCH_FPV5_SP_D16 default "" config CONFIG_TFM_FP_ARCH_ASM string default "FPv5_D16" if FP_ARCH_FPV5_D16 default "" Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

3 years, 6 months

2
1
0 0

Release v1.8.0 changes are merged.

by Anton Komlev

Hello, The changes made for the TF-M v1.8.0 are merged back to the master branch. To allow that, Corstone-1000 platform was temporarily excluded from OpenCI tests because the platform changes in the release branch conflicted with changes in the master, made in parallel. The platform will be back under test immediately after the conflict resolution. Corstone-1000 platform builds and runs correctly under v1.8.0 tag. Thanks, Anton

3 years, 6 months

1
0
0 0

TF-M release v1.8.0 announcement

by Anton Komlev

Hello, I am pleased to announce the release of TF-M v1.8.0<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.8…>. New major features are: * TF-M eRPC Test framework 1 is integrated. * TF-M builtin key loader integration is reworked. * Improved crypto library abstraction from TF-M Crypto service. * Kconfig system is enhanced and finalized. * Switch to upstream QCBOR 2. * Enable PSA Authenticated Debug Access Control (ADAC) 3 support on Musca-B1 platform. * Support Floating-Point (FP) with Arm Compiler. * FF-M API uses signals to drive the partition scheduling instead of controlling partition context directly. * MCUboot upgrade to v1.10.0. * Mbed TLS upgrade to v3.4.0. * Refine documentation restructure. * It is optional to update copyright year in changes. Requirements of copyright note update is updated in Contributing Process. Please check the release notes<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/relea…> 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

3 years, 6 months

1
0
0 0

SVC handlers refining

by Ken Liu

Hello, For isolation levels > 1, partitions need to SVC for PSA APIs. To improve the efficiency of this call type, the SVC handler needs to be simplified. Currently, there are several obvious places to be improved: - Handlers in C have multiple-level function calling; - There are a couple of checks in the handler routine that can be refined. And, to take advantage of instruction TBB, the switch/case number needs to be linear - but it is not always stable hence needs to investigate if a handmade function table would be more stable. The leading patches are here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20644 Feel free to comment or reply in this thread. Thanks. /Ken

3 years, 6 months

1
0
0 0

Adjustments for SVC number assignments that impact platforms with platform-specific SVC

by Kevin Peng

Hi, We're making some adjustments for the SVC number assignments. I'd like to collect some feedbacks, especially from downstream platforms that have your own SVC handler because corresponding changes of your SVC numbers are required when these changes were accepted. Originally, The SVC numbers are categorized by their values, for example, numbers less than 0x40 are PSA API requests and numbers larger than 0x80 are for handler mode. This is not convenient for adding new SVC because it's not intuitive to find a proper value range. More importantly, it's easy to create clashes between TF-M and platform SVC by mistake as they are defined in different files. So, we propose to divide the SVC number bits into different fields for distinguishing different types of SVC. Please see here<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20644/1/secu…> for the detailed descriptions. With these changes, it's much easier to put the SVC numbers in the right range and avoid duplications after setting the bit fields to right values. Thanks, Kevin

3 years, 6 months

1
0
0 0

ITS cmake

by Quach, Brian

Is the highlighted line below correct? Or should the angle bracket be at the end like this: $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/../protected_storage> target_include_directories(tfm_psa_rot_partition_its PRIVATE $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> ${CMAKE_BINARY_DIR}/generated/secure_fw/partitions/internal_trusted_storage PUBLIC # Required for ps_object_defs.h $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>/../protected_storage ) Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

3 years, 6 months

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M