Dear Hao,
thanks for your email and apologies for the late reply. To anwer to your points below:
1. A driver is free to implement each entry point (in your example below, the "abort" entry point for an AEAD multipart operation), as it sees fit. While in principle there is nothing wrong in implementing the abort as a PSA_ERROR_NOT_SUPPORTED function, note that the behaviour of the callers is usually to expect that if a function (or entry point) is implemented, an error code would actually signal an error with the operation itself. In your case, I see it more as a no-op operation which returns PSA_SUCCESS; Returning PSA_ERROR_NOT_SUPPORTED would imply, in my view, that the operation abort has failed because the API is not supported yet, thus leading to several application logic to just completely declare the entire multipart operation as failed, i.e. detecting the HW entered a non-consistent state 2. The driver interface (i.e. the entry points) are indeed plugged into the autogenerated driver wrapper header (i.e. a collection of static functions). Ideally, a driver would be described by a JSON file that gets parsed by the autogen framework at build time and the resulting entry points for the driver are placed in the correct places on the autogenerated file. In practice, this feature is still not fully completed on Mbed TLS side and TF-M is yet to make proper usage of it. Currently, we are hardcoding the entry points directly into the driver wrapper itself (keeping a generated copy of it in the repo we check out, and not autogenerating it at build). See the patch lib/ext/mbedcrypto/0005-Hardcode-CC3XX-entry-points.patch which gets applied on the Mbed TLS depedency used by the Crypto service at build time for the CC3XX driver. This is far from ideal and we have on our roadmap to work towards the proper driver integration strategy using JSON files and the autogen framework. As an intermediate step to facilita the work of several integrators, we might avoid hardcoding the driver wrapper itself and we might modify the jinja template explicitly for the CC3XX driver, just as intermediate step in future releases if the full solution won't be available by then. The actual location of the entry points in the TF-M tree should be then under the platform directory for each target platform that has a PSA crypto driver. The important aspect is that at link time, the static library which defines the implementation of the entry points, is visible to the Crypto service build so that correct integration can be performed (i.e. symbol names can be resolved). You mention a thread where the jinja template is discussed to be removed, I am not aware of that at the moment, but in general TF-M will just try to work out with whoever solution will be recommended by the Mbed TLS autogen framework at the time (just to iterated, I am not aware that there is anything different being planned at the moment but please point me to it if you know otherwise).
Hope this answers your question. Any other doubt, feel free to ask here.
Thanks, Antonio ________________________________ From: Zhang, Hao via TF-M tf-m@lists.trustedfirmware.org Sent: Wednesday, June 5, 2024 00:37 To: tf-m@lists.trustedfirmware.org 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.
1. 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-... 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? 2. 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?
[https://opengraph.githubassets.com/c87e79773a7fb0841ea038f7cf3dfdf4170debb86...]https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa-driver-interface.md#general-considerations-on-multi-part-operations mbedtls/docs/proposed/psa-driver-interface.md at zephyr · zephyrproject-rtos/mbedtlshttps://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa-driver-interface.md#general-considerations-on-multi-part-operations mbedtls module for Zephyr, this is not a mirror of the official mbedtls repository. - zephyrproject-rtos/mbedtls github.com
Thank you very much!
Best regards