Hi Gilles,

Thank you very much for your answer, it helps a lot! I have some follow up questions. Thank you in advance.

  1. For multi-part operation, as you mentioned, the abort needs to deallocate resources. If there are some restrictions that prevents deallocating resources in the middle of aead operation, could it be that aead_abort returns PSA_ERROR_NOT_SUPPORTED?

  2. Thank you for your information about future JSON only framework. But as of now for TF-M v2.1.0 LTS, is it right that psa_crypto_driver_wrappers.h.jinja file, the driver description file in JSON, and entry point functions need to be implemented for TF-M to work with customized HW accelerator? If so, could they all be included in TF-M repo under platform/ext/accelerator/<vendor name> directory? 

Thank you very much!

Best regards,

Hao

From: Gilles Peskine <gilles.peskine@arm.com>
Sent: Wednesday, June 5, 2024 11:57 AM
To: Shebu Varghese Kuriakose <Shebu.VargheseKuriakose@arm.com>; Zhang, Hao <Hao.Zhang@analog.com>; tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>; mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: Re: [mbed-tls] Re: PSA Cryptoprocessor Driver Interface
 
[External]

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