- TF-M - lists.trustedfirmware.org

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

2
1
0 0

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 year, 2 months

1
1
0 0

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 year, 2 months

1
0
0 0

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 year, 2 months

2
1
0 0

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 year, 2 months

2
2
0 0

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 year, 2 months

4
3
0 0

Please unsubscribe

by Kirill Konevets

Unsubscribe me please

1 year, 2 months

3
2
0 0

TF-M Tech forum time update proposal

by Anton Komlev

Hi, Following the forum session today I am sending this separate email asking for your feedback. The recent forums on the East time zone slot are getting quite low attendance, so I am wondering if it still valuable or we want to reschedule it. The potential options I can think of: 1. Keep the current schedule and change nothing. 2. Drop the East time zone slot and leave West time zone slot only for monthly meetings. 3. Reschedule slots for bi-weekly forums on West time zone. 4. Other ideas? Thanks, and please share your opinion in this email thread, Anton

1 year, 3 months

1
0
0 0

NS Client ID mapping for Hybrid Platform

by Mate Toth-Pal

Hi All, As part of the work we are doing for Hybrid Platforms we prepared a patch that makes changes how the Non-Secure Client IDs are handled. When TF-M is run in Hybrid Platform configuration, It has multiple NS agents active the same time. Each of the NS clients (either running in the NSPE the same v8M CPU as SPM, or on the other end of a Mailbox) can have their own way to assign NS Client IDs to clients. To prevent NS clients impersonate other NS clients that are accessing secure services through a different agent, the patch introduces Client ID mapping. For each NS agent partition a range of valid Client IDs is defined in the manifest yaml file. The SPM checks boot time that the ranges don't overlap. The NS agent partitions must make sure that they map incoming client ID's in a way that the output Client ID is always in the range of valid IDs for that NS agent. If an NS agent has multiple mailboxes, it is possible to assign separate ranges for those mailboxes (the range is associated with the Mailbox IRQ in the manifest yaml). Please find the patch here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/26947 Any questions or comments are welcome! Best Regards, Mate

1 year, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M