Hello,

  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-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?
A driver that implements a multi-part operation must implement all the entry points. If the driver's aead_setup returns PSA_SUCCESS, then the driver's other entry points will be called for aead_update_ad, aead_update, etc. If one of these entry points returns an error, that error is returned to the application.

Regarding abort entry points, many accelerator drivers don't need to do anything. If so, just return PSA_SUCCESS. The core will wipe the memory used by the context structure. Drivers need to do more work in an abort entry point if they allocate a resource that needs to be deallocated, for example a secure element driver that opens a connection to the secure element during setup.


  1. 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?

When driver support is fully implemented in Mbed TLS, the header files will be generated from the JSON description. I don't have a timeline for when that will happen.

Best regards,

--
Gilles Peskine
PSA Crypto architect and Mbed TLS developer