+ 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.
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?
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?
[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
Hello,
- 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-... 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.
- 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,
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-...https://urldefense.com/v3/__https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa-driver-interface.md*general-considerations-on-multi-part-operations__;Iw!!A3Ni8CS0y2Y!6cgNxL7-oddYhCJtNJxCBNwmjPyAUiILCUNuze8TFgRGi-F1WhmD9e2kZupVS0tYMi9exZtsb6YUei9br7bZ9SI$ 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
I'll just answer the interface question, I don't know about the TF-M part.
On 05/06/2024 22:48, Zhang, Hao wrote:
- 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?
No, the driver should not return NOT_SUPPORTED, because an application has no good way to react to that. The application would have an operation object that can neither be used nor freed. In practice applications may either ignore errors from abort() or panic.
abort() can always be implemented by simulating a complete operation (e.g. finish() or verify()) with empty inputs, ignoring any further output.
But I'm curious: what would prevent deallocating resources? The only thing I can think of is concurrency, but operations are sequential: there can't be concurrent calls on the same operation object from different threads, so abort() won't be called while another thread has the operation locked.
Best regards,
Hi Gilles,
Thank you very much for your answer. It makes a lot of sense! As of the restriction, it is something with the hardware.
Appreciate your answer very much!
Best regards,
Hao ________________________________ From: Gilles Peskine gilles.peskine@arm.com Sent: Thursday, June 6, 2024 1:05 PM To: Zhang, Hao Hao.Zhang@analog.com; Shebu Varghese Kuriakose Shebu.VargheseKuriakose@arm.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]
I'll just answer the interface question, I don't know about the TF-M part.
On 05/06/2024 22:48, Zhang, Hao wrote:
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?
No, the driver should not return NOT_SUPPORTED, because an application has no good way to react to that. The application would have an operation object that can neither be used nor freed. In practice applications may either ignore errors from abort() or panic.
abort() can always be implemented by simulating a complete operation (e.g. finish() or verify()) with empty inputs, ignoring any further output.
But I'm curious: what would prevent deallocating resources? The only thing I can think of is concurrency, but operations are sequential: there can't be concurrent calls on the same operation object from different threads, so abort() won't be called while another thread has the operation locked.
Best regards,
-- Gilles Peskine
mbed-tls@lists.trustedfirmware.org
-
Gilles Peskine -
Shebu Varghese Kuriakose -
Zhang, Hao