+ Mbed TLS mailing list as well for visibility and any comments.
Regards,
Shebu
From: Zhang, Hao via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, June 5, 2024 12:37 AM
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] PSA Cryptoprocessor Driver Interface
Hi TF-M community,
TF-M allows Semiconductor vendors to plug in their HW accelerator using PSA cryptoprocessor driver interface. I have a couple of questions in terms of the driver interface.
-
To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS using driver interface, for the multipart operation,
https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa-driver-interface.md#general-considerations-on-multi-part-operations states that "A driver that implements a multi-part operation must define all of the entry points in this family
as well as a type that represents the operation context." Take aead encrypt as an example, if the underlying hardware does not support aead_abort, could it implements aead_abort by simply return PSA_ERROR_NOT_SUPPORTED?
-
The driver interface depends heavily on psa_crypto_driver_wrappers.h to dispatch operations to customized HW accelerator, where the psa_crypto_driver_wrappers.h file is automatically generated by scripts/data_files/driver_templates/psa_crypto_driver_wrappers.h.jinja.
To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS, would the approach be creating a customized
psa_crypto_driver_wrappers.h.jinja file, the driver description file in JSON, and entry point functions. If so and we are considering upstreaming TF-M in the future, all these files would go inside platform/ext/accelerator/<vendor name>. Efforts need
to be made so files such as psa_crypto_driver_wrappers.h.jinja should point to mbedtls, right? Additionally, as .jinja is retiring (mentioned in another email exchange), how would semi vendors update
psa_crypto_driver_wrappers.h in the future?
Thank you very much!
Best regards