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
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
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
+ 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
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
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
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
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
Hi folks,
I tried running a minimal example on the nRF9160dk.
In `boot_hal_bl2.c` the following code is executed:
#ifdef FLASH_DEV_NAME
result = FLASH_DEV_NAME.Uninitialize();
if (result != ARM_DRIVER_OK) {
while(1) {}
}
#endif /* FLASH_DEV_NAME */
For the Nordic boards `Uninitialize` is not implemented (see
`Driver_Flash.c`):
ARM_DRIVER_FLASH Driver_FLASH0 = {
.GetVersion = NULL,
.GetCapabilities = ARM_Flash_GetCapabilities,
.Initialize = ARM_Flash_Initialize,
.Uninitialize = NULL,
.PowerControl = NULL,
.ReadData = ARM_Flash_ReadData,
.ProgramData = ARM_Flash_ProgramData,
.EraseSector = ARM_Flash_EraseSector,
.EraseChip = NULL,
.GetStatus = NULL,
.GetInfo = ARM_Flash_GetInfo
};
This leads to a non-zero value being stored in `result` and my program
ends up getting stuck in the while loop.
Is it possible to fix that?
Kind regards,
Lena