Hi mbed-tls Team,
PSA crypto API for HW acceleration seems pretty new. Question1: is there some reference code or project I could poke around to see how it is being used?
Currently I have added (locally) a set of driver to make use of our HW crypto using the *_ALT way (the old way?) and for what I understand, the PSA API is the "new way" to do things. But It is still unclear how vendor do upstream there HW acceleration drivers. If this part is kept in another repo, then the mbedTLS build does not have any "hooks" to pull-in the vendor specific code to build the mbedTLS library with.
The current implementation seems to be agnostic to any vendor specific HW so I am wondering if there is a "standard" way for vendor to upstream their mbedTLS HW acceleration code that would be built as part of mbedTLS library.
I have posted a similar thread to the "issue" ticket of the mbedtls repo for reference: https://github.com/Mbed-TLS/mbedtls/issues/5975 Thanks for any feedback/pointers/ideas. Regards, -Mathieu
Hi,
Regarding question1, we have developed the PSA driver interface for the Arm CryptoCell 312 and the reference code is available here: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/lib/ext/cry...
The upstream work has been tracked here for reference: https://developer.trustedfirmware.org/tag/psa_cryptoprocessor_driver_interfa...
Thanks, Antonio
-----Original Message----- From: mathieu.rondonneau--- via mbed-tls mbed-tls@lists.trustedfirmware.org Sent: Monday, June 27, 2022 18:27 To: mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] *_ALT vs PSA for HW crypto and upstreaming
Hi mbed-tls Team,
PSA crypto API for HW acceleration seems pretty new. Question1: is there some reference code or project I could poke around to see how it is being used?
Currently I have added (locally) a set of driver to make use of our HW crypto using the *_ALT way (the old way?) and for what I understand, the PSA API is the "new way" to do things. But It is still unclear how vendor do upstream there HW acceleration drivers. If this part is kept in another repo, then the mbedTLS build does not have any "hooks" to pull-in the vendor specific code to build the mbedTLS library with.
The current implementation seems to be agnostic to any vendor specific HW so I am wondering if there is a "standard" way for vendor to upstream their mbedTLS HW acceleration code that would be built as part of mbedTLS library.
I have posted a similar thread to the "issue" ticket of the mbedtls repo for reference: https://github.com/Mbed-TLS/mbedtls/issues/5975 Thanks for any feedback/pointers/ideas. Regards, -Mathieu
Hi Mathieu,
To integrate a driver, the idea is to instruct the build system what drivers are available, and a script will generate .c and .h files with the required declarations and dispatch code. https://github.com/Mbed-TLS/mbedtls/blob/development/docs/proposed/psa-drive... is a draft of how this will look like. Unfortunately, we have only just started to implement this (the current work in progress is https://github.com/Mbed-TLS/mbedtls/pull/5396). So in the meantime, you need to edit library/psa_crypto_driver_wrappers.c and include/psa/crypto_driver_contexts*.h manually.
We currently have no plans for managing the upstreaming of drivers. One reason is that we're a bit uncomfortable hosting code that we can't test, and setting up testing for all the hardware is a big job in itself. Another reason is that driver code tends to depend on the operating system or runtime environment — it needs to map memory, react to interrupts, etc.
For those reasons, my personal opinion is that rather than Mbed TLS managing driver upstreaming, this will be done by platforms such as Mbed OS, Zephyr, etc. Mbed OS, at least, has already included many Mbed TLS ALT implementations for years, and will gradually include PSA crypto drivers.
Best regards,
mbed-tls@lists.trustedfirmware.org