search

Mbed-TLS / mbedtls

An open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.
https://www.trustedfirmware.org/projects/mbed-tls/
Other
5.06k stars 2.52k forks source link

PSA will support drivers in that way in the future, so that developers don't have to change the mbedtls code. #9339

Open liwei62 opened 1 week ago

liwei62 commented 1 week ago

Does the PSA support the implementation of dynamically registered transparent drivers? Even if opaque drivers support registration, the method in the PSA_CRYPTO_DRIVER_TEST macro is still used in practice, for example, psa_driver_wrapper_mac_compute.

This requires intrusive changes to mbedtls code whether I implement transparent drivers or opaque drivers. PSA will support drivers in that way in the future, so that developers don't have to change the mbedtls code. It's not supported yet, right?

gilles-peskine-arm commented 1 week ago

We do not support dynamically registered transparent drivers and we do not currently intend to. What is the use case for dynamically loading an accelerator driver? Mbed TLS primarily targets constrained devices where the manufacturer typically puts together a base image or an SDK that includes the necessary drivers.

We currently have partial support for dynamically registered secure element drivers, but that is based on an early draft of the driver design and incomplete, and we're planning to remove it in the next major version of the library.

Implementing a driver currently requires changes in Mbed TLS, but that's a different matter. Our plan for driver integration is a script that generates the driver wrapper code from a description of the drivers' capabilities. Unfortunately that script is only about 5% done at the moment, which is why you need to edit some files. It's also why those files currently contain references to test drivers. Once that script is finished, drivers will need to be registered at compile time, but that will just be one step in the build process.

liwei62 commented 1 week ago

We do not support dynamically registered transparent drivers and we do not currently intend to. What is the use case for dynamically loading an accelerator driver? Mbed TLS primarily targets constrained devices where the manufacturer typically puts together a base image or an SDK that includes the necessary drivers.

We currently have partial support for dynamically registered secure element drivers, but that is based on an early draft of the driver design and incomplete, and we're planning to remove it in the next major version of the library.

Implementing a driver currently requires changes in Mbed TLS, but that's a different matter. Our plan for driver integration is a script that generates the driver wrapper code from a description of the drivers' capabilities. Unfortunately that script is only about 5% done at the moment, which is why you need to edit some files. It's also why those files currently contain references to test drivers. Once that script is finished, drivers will need to be registered at compile time, but that will just be one step in the build process.

The future mbedtls evolution direction is to support transparent drivers or opaque drivers through construction, where automation scripts are mainly used to avoid modifying mbedtls code. Is there no plan to support a mechanism for dynamically registering providers like openssl?

gilles-peskine-arm commented 1 week ago

Is there no plan to support a mechanism for dynamically registering providers like openssl?

Currently, no. Mbed TLS is primarily intended for devices with limited resources where a dynamic loading mechanism is too large.

What is your use case for dynamic loading? We aren't fundamentally opposed to having it as an extra feature, but it's more development work and more maintenance overhead, so we need to have a solid justification and possibly some help.

liwei62 commented 1 week ago

What is your use case for dynamic loading? We aren't fundamentally opposed to having it as an extra feature, but it's more development work and more maintenance overhead, so we need to have a solid justification and possibly some help.

Sorry, I don't have a specific scenario, just a simple comparison with openssl. Thank you for your answer.