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
+ 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
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
Hi Antonio,
Thank you very much! It helps resolve my questions. Just to confirm for the second question, if a customized HW accelerator (that is similar to CC312) would like to be plugged into PSA cryptoprocessor driver interface, a new patch similar to lib/ext/mbedcrypto/0005-Hardcode-CC3XX-entry-points.patch would be created under platform/ext/target/<vendor> and set ${MBEDCRYPTO_FORCE_PATCH} pointing to the newly created patch. Is that right? And as jinja files are not fully completed and will be released in the future, for TF-M v.2.1.0 LTS, is it not recommended to use jinja as the method for integrating customized HW accelerator?
Best regards,
Hao
________________________________ From: Antonio De Angelis Antonio.DeAngelis@arm.com Sent: Wednesday, June 5, 2024 5:58 PM To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org; Zhang, Hao Hao.Zhang@analog.com Cc: nd nd@arm.com Subject: Re: PSA Cryptoprocessor Driver Interface
[External]
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-...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!8dl-6f-bB8lb61YG2MsNINws0NmsdISr1xv4WCPTZFiQuHWfs0mCO5Ufrrra8D-Wq1OW7ijNc184jAR7gyjniuFttg$ 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://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!8dl-6f-bB8lb61YG2MsNINws0NmsdISr1xv4WCPTZFiQuHWfs0mCO5Ufrrra8D-Wq1OW7ijNc184jAR7gyjniuFttg$ mbedtls/docs/proposed/psa-driver-interface.md at zephyr · zephyrproject-rtos/mbedtlshttps://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!8dl-6f-bB8lb61YG2MsNINws0NmsdISr1xv4WCPTZFiQuHWfs0mCO5Ufrrra8D-Wq1OW7ijNc184jAR7gyjniuFttg$ 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
Hi Hao,
yes either that or just put a patch under lib/ext/mbedcrypto/000X-XXXX.patch , currently the CC3XX driver which is platform specific is anyway hosted there as a patch which is applied on any platform (it won't have any effect if the platform build itself does not set the proper define anyway).
This should be enough at this stage, we will try to have a look into the autogen framework more organically at some point.
Thanks, Antonio ________________________________ From: Zhang, Hao Hao.Zhang@analog.com Sent: Monday, June 10, 2024 15:53 To: Antonio De Angelis Antonio.DeAngelis@arm.com; tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: PSA Cryptoprocessor Driver Interface
Hi Antonio,
Thank you very much! It helps resolve my questions. Just to confirm for the second question, if a customized HW accelerator (that is similar to CC312) would like to be plugged into PSA cryptoprocessor driver interface, a new patch similar to lib/ext/mbedcrypto/0005-Hardcode-CC3XX-entry-points.patch would be created under platform/ext/target/<vendor> and set ${MBEDCRYPTO_FORCE_PATCH} pointing to the newly created patch. Is that right? And as jinja files are not fully completed and will be released in the future, for TF-M v.2.1.0 LTS, is it not recommended to use jinja as the method for integrating customized HW accelerator?
Best regards,
Hao
________________________________ From: Antonio De Angelis Antonio.DeAngelis@arm.com Sent: Wednesday, June 5, 2024 5:58 PM To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org; Zhang, Hao Hao.Zhang@analog.com Cc: nd nd@arm.com Subject: Re: PSA Cryptoprocessor Driver Interface
[External]
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-...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!8dl-6f-bB8lb61YG2MsNINws0NmsdISr1xv4WCPTZFiQuHWfs0mCO5Ufrrra8D-Wq1OW7ijNc184jAR7gyjniuFttg$ 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://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!8dl-6f-bB8lb61YG2MsNINws0NmsdISr1xv4WCPTZFiQuHWfs0mCO5Ufrrra8D-Wq1OW7ijNc184jAR7gyjniuFttg$ mbedtls/docs/proposed/psa-driver-interface.md at zephyr · zephyrproject-rtos/mbedtlshttps://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!8dl-6f-bB8lb61YG2MsNINws0NmsdISr1xv4WCPTZFiQuHWfs0mCO5Ufrrra8D-Wq1OW7ijNc184jAR7gyjniuFttg$ 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
Hi Antonio,
Got it. Thank you very much!
Best regards,
Hao ________________________________ From: Antonio De Angelis Antonio.DeAngelis@arm.com Sent: Monday, June 10, 2024 3:11 PM To: Zhang, Hao Hao.Zhang@analog.com; tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: PSA Cryptoprocessor Driver Interface
[External]
Hi Hao,
yes either that or just put a patch under lib/ext/mbedcrypto/000X-XXXX.patch , currently the CC3XX driver which is platform specific is anyway hosted there as a patch which is applied on any platform (it won't have any effect if the platform build itself does not set the proper define anyway).
This should be enough at this stage, we will try to have a look into the autogen framework more organically at some point.
Thanks, Antonio ________________________________ From: Zhang, Hao Hao.Zhang@analog.com Sent: Monday, June 10, 2024 15:53 To: Antonio De Angelis Antonio.DeAngelis@arm.com; tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: PSA Cryptoprocessor Driver Interface
Hi Antonio,
Thank you very much! It helps resolve my questions. Just to confirm for the second question, if a customized HW accelerator (that is similar to CC312) would like to be plugged into PSA cryptoprocessor driver interface, a new patch similar to lib/ext/mbedcrypto/0005-Hardcode-CC3XX-entry-points.patch would be created under platform/ext/target/<vendor> and set ${MBEDCRYPTO_FORCE_PATCH} pointing to the newly created patch. Is that right? And as jinja files are not fully completed and will be released in the future, for TF-M v.2.1.0 LTS, is it not recommended to use jinja as the method for integrating customized HW accelerator?
Best regards,
Hao
________________________________ From: Antonio De Angelis Antonio.DeAngelis@arm.com Sent: Wednesday, June 5, 2024 5:58 PM To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org; Zhang, Hao Hao.Zhang@analog.com Cc: nd nd@arm.com Subject: Re: PSA Cryptoprocessor Driver Interface
[External]
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-...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!8dl-6f-bB8lb61YG2MsNINws0NmsdISr1xv4WCPTZFiQuHWfs0mCO5Ufrrra8D-Wq1OW7ijNc184jAR7gyjniuFttg$ 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://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!8dl-6f-bB8lb61YG2MsNINws0NmsdISr1xv4WCPTZFiQuHWfs0mCO5Ufrrra8D-Wq1OW7ijNc184jAR7gyjniuFttg$ mbedtls/docs/proposed/psa-driver-interface.md at zephyr · zephyrproject-rtos/mbedtlshttps://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!8dl-6f-bB8lb61YG2MsNINws0NmsdISr1xv4WCPTZFiQuHWfs0mCO5Ufrrra8D-Wq1OW7ijNc184jAR7gyjniuFttg$ 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
tf-m@lists.trustedfirmware.org
-
Antonio De Angelis -
Gilles Peskine -
Shebu Varghese Kuriakose -
Zhang, Hao