Hi Ruchika,
We are planning to complete the work to generate driver wrappers from
the JSON, but we don't know when.
From a technical standpoint, we're likely to move away from the Jinja
code and use only basic Python, with a function wrapper generator that
we'll maintain and that we'll use for multiple purposes. So at this
point we probably won't spend much effort on integrating patches to the
Jinja templates or the corresponding Python code.
We do welcome reports and patches on how this works out for those of you
who are maintaining drivers. Please let us know what does and doesn't
work for you.
Best regards,
--
Gilles Peskine
Mbed TLS developer
On 05/04/2024 12:45, Ruchika Gupta via mbed-tls wrote:
>
> + tf-m mailing list
>
> *From:* Ruchika Gupta
> *Sent:* Friday, April 5, 2024 4:14 PM
> *To:* tf-m <"tf-m@lists.trustedfirmware.org
> <tf-m"@lists.trustedfirmware.org>; mbed-tls@lists.trustedfirmware.org;
> security-wg@lists.zephyrproject.org
> *Subject:* Use of auto-generation approach for mbedtls/mbed-crypto
> driver psa_crypto_driver_wrappers..h file
>
> Hi All,
>
> Apologies for the long email. I am adding all the 3 projects (TF-M,
> mbedTLS and Zephyr) to the mail chain because the issues I discuss
> below are inter-connected and affect all the three projects.
>
> From mbedtls 3.5.0 version, the mbedtls project has migrated to
> auto-generated psa_crypto_driver_wrappers.h file.
>
>
https://github.com/Mbed-TLS/mbedtls/blob/development/docs/psa-driver-example...
>
>
https://github.com/Mbed-TLS/mbedtls/blob/development/docs/proposed/psa-drive...
>
> On TF-M, mbed-crypto, there are 2 patches for the drivers given below
> which are still hardcoding their changes and not following the above
> approach.
>
> 1. PSA_CRYPTO_DRIVER_TFM_BUILTIN_KEY_LOADER
> (0001-Add-TF-M-Builtin-Key-Loader-driver-entry-points.patch)
> 2. PSA_CRYPTO_DRIVER_CC3XX (0005-Hardcode-CC3XX-entry-points.patch)
>
> We at NXP, have migrated our psa crypto wrappers to the above approach
> using auto-generation. We want to maintain same code base for mbedtls
> for our SDK’s, TFM mbed-crypto as well as align mbedTLS fork in Zephyr.
>
> We are increasingly finding it difficult to migrate to newer versions
> of mbedtls because of hardcoding of above drivers. The problem is
> specially on the Zephyr front, where in the mbedTLS fork in zephyr
> these patches from tfm are applied by default.
>
> I have queries for all the 3 projects listed below :
>
> TF-M à Can you please let us know what are the plans to migrate these
> 2 drivers in tfm to the auto-generation approach. If these patches can
> be migrated to make changes in jinja files rather than hardcoding in
> psa_crypto_driver_wrappers , things would be much easier to integrate.
>
> Is somebody already working on it ? Are you open to accept patches for
> this change ?
>
> mbedTLS à What is the long term strategy from mbedTLS on this
> auto-generation ? We still have a lot of hard-coding in .jinja file
> rather than using drivers.json. Would mbedTLS/new PSA crypto
> repository start accepting patches for psa wrappers from platforms ?
> Can the patches which TF-M project maintains be merged in the mbedTLS ?
>
> Zephyr à On Zephyr front, what are the plans to align to this
> auto-generation approach ?
>
> Regards,
>
> Ruchika
>
>