Hi,
Using isolation level 1 and IPC secure partition, I noticed psa_call() overhead for TFM v1.7 is significantly worse for than v1.1. Is this expected?
Assuming 1 invec and 0 outvec for the PSA call....
TF-M version
Psa_call() round trip cycles
v1.1
4038
v1.7
6051
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Hi,
Currently in the Attestation partition, when encoding the security lifecycle, boot seed, and hardware version claims, these info are searched in the shared memory firstly before calling the platform hal APIs. See the code here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>. Sharing this information via shared memory is a legacy mechanism and MCUboot does not writes that information when booting. And calling the platform hal APIs way is recommended. I created this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/21021> removes looking for the security lifecycle, boot seed, and hardware version from shared memory. Before opening this patch for review, I would like to query whether this mechanism is being used by any platform.
Is there any platform(which suppose runs a bootloader which is not MCUboot) using this sharing memory mechanism to provide the security lifecycle, boot seed, and hardware version information now?
Thanks,
Regards,
Sherry Zhang
Hi everyone,
Some time ago patch for split build<https://review.trustedfirmware.org/q/topic:%2522split-build%2522> of SPE, NSPE, BL2 was announced.
I am interested on when this patch is planned to be merged?
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>
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
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
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
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
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
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
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