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