TF-M April 2024

tf-m@lists.trustedfirmware.org

14 participants
17 discussions

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 month, 1 week

Upcoming TF-M release heads up.

by Anton Komlev

Hello, We plan to initiate TF-M v2.1.0 release with a feature freeze on April 8th targeting completion before April 28th. Please let me know if there are pending patches critical to be included in this release and shall be merged before the feature freeze. Thanks, Anton

1 month, 1 week

TF-M support for Mbed TLS 3.6.0-LTS

by Antonio De Angelis

Hi all, Mbed TLS 3.6.0-LTS has been recently released and we are in the process of upgrading the supported version of TF-M as well. I have prepared three patches (for tests, extras and the main repo) available here for review that need to be merged by the time the release freeze happens (likely this week at some point). From this patch onwards, TF-M will align completely to the PSA Crypto headers shipped by the Mbed TLS project, hopefully solving the issues we have had in the past around header mismatches when both Mbed TLS and TF-M Crypto are integrated into the same environment. For this reason the TF-M project will just hold a copy of the headers (in the interface/include/psa and interface/include/mbedtls directories) and won't accept any contribution to them. Please find the patches available for review under the following Gerrit topic: topic:"mbedtls_3_6_0_alignment" · Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/q/topic:%22mbedtls_3_6_0_alignment%22> Thanks, Antonio

1 month, 1 week

Re: Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file

by Ruchika Gupta

+ tf-m mailing list From: Ruchika Gupta Sent: Friday, April 5, 2024 4:14 PM To: tf-m <"tf-m(a)lists.trustedfirmware.org <tf-m"@lists.trustedfirmware.org>; mbed-tls(a)lists.trustedfirmware.org; security-wg(a)lists.zephyrproject.org Subject: Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file Hi All, Apologies for the long email. I am adding all the 3 projects (TF-M, mbedTLS and Zephyr) to the mail chain because the issues I discuss below are inter-connected and affect all the three projects. From mbedtls 3.5.0 version, the mbedtls project has migrated to auto-generated psa_crypto_driver_wrappers.h file. https://github.com/Mbed-TLS/mbedtls/blob/development/docs/psa-driver-exampl… https://github.com/Mbed-TLS/mbedtls/blob/development/docs/proposed/psa-driv… On TF-M, mbed-crypto, there are 2 patches for the drivers given below which are still hardcoding their changes and not following the above approach. 1. PSA_CRYPTO_DRIVER_TFM_BUILTIN_KEY_LOADER (0001-Add-TF-M-Builtin-Key-Loader-driver-entry-points.patch) 2. PSA_CRYPTO_DRIVER_CC3XX (0005-Hardcode-CC3XX-entry-points.patch) We at NXP, have migrated our psa crypto wrappers to the above approach using auto-generation. We want to maintain same code base for mbedtls for our SDK's, TFM mbed-crypto as well as align mbedTLS fork in Zephyr. We are increasingly finding it difficult to migrate to newer versions of mbedtls because of hardcoding of above drivers. The problem is specially on the Zephyr front, where in the mbedTLS fork in zephyr these patches from tfm are applied by default. I have queries for all the 3 projects listed below : TF-M --> Can you please let us know what are the plans to migrate these 2 drivers in tfm to the auto-generation approach. If these patches can be migrated to make changes in jinja files rather than hardcoding in psa_crypto_driver_wrappers , things would be much easier to integrate. Is somebody already working on it ? Are you open to accept patches for this change ? mbedTLS --> What is the long term strategy from mbedTLS on this auto-generation ? We still have a lot of hard-coding in .jinja file rather than using drivers.json. Would mbedTLS/new PSA crypto repository start accepting patches for psa wrappers from platforms ? Can the patches which TF-M project maintains be merged in the mbedTLS ? Zephyr --> On Zephyr front, what are the plans to align to this auto-generation approach ? Regards, Ruchika

1 month, 1 week

MCUBOOT_SWAP_USING_MOVE vs MCUBOOT_SWAP_USING_SCRATCH

by Tomasz Jastrzębski

Hi All, I apologize for this probably trivial question, but I cannot find out if and why I should use MCUBOOT_SWAP_USING_MOVE or MCUBOOT_SWAP_USING_SCRATCH. Are there any real advantages of move with SCRATCH other than that it requires less flash? - that is, min just one extra sector for all the images vs min one sector per image? Move without scratch seems to provide a better wear balance but still almost all the examples I come across use move with scratch. What am I missing? Kind regards, Tomasz

1 month, 1 week

Windows 10 error file name or extension too long

by Michael Khoyilar

Hi all I am new to TF-M and want to know if there is a public forum to post questions or search for answers? I am getting this error under Windows 10 when making clean: make (e=206): The filename or extension is too long Thank you Michael

1 month, 1 week

Please unsubscribe

by Kirill Konevets

Unsubscribe me please

1 month, 1 week

2024

2023

2022

2021

2020

2019

2018

TF-M April 2024