[zep noup] add ESP32 PSA crypto transparent driver dispatch

[sylvioalves]

Add PSA crypto driver dispatch blocks for ESP32 hardware acceleration covering cipher (AES), hash (SHA), AEAD (AES-GCM), and MAC (CMAC) operations. Uses fallback pattern so unsupported algorithms are handled by software.

Add ESP32 driver context types to the primitives and composites context union headers.

[frkv]

Hey. The psa_crypto_driver_wrappers.h file you are trying to add to contains only one HW accelerator for a very specific reason. the CC3XX support comes from applied patches in TF-M which is directly integrated towards Mbed TLS solution to be TF-M compatible

Adding other hardware accelerators here will make this automatically applied patch impossible to do without conflicts.

I strongly recommend writing and retaining a device-specific version of psa_crypto_driver_wrappers.h and any vendor-specific header-files for context types instead.

Tagging: @nicola-mazzucato-arm for visibility (Code owner(?) in Arm TF-M)

[ruchi393]

Hi @frkv , till the driver specific repo ,headers and makefiles are finalized and made available ,can we first apply TF-M patches and on top of that vendors's can add their psa driver like done by this patch. Vendor's can be then responsible for maintaining these patches and porting them to newer versions in this case to the tf-psa-crypto.

@valeriosetti , I am assuming the current plan would be to have pre-generated files in tf-psa-crypto and then apply the patches from tf-m on top of it. If yes, vendors should be allowed to manually add patches on top like done by tf-m till we have a clear separation available.

[valeriosetti]

@valeriosetti , I am assuming the current plan would be to have pre-generated files in tf-psa-crypto

I would say so. This will be discussed today during the Security WG meeting, but I think it makes sense given that we need at least to apply patches from TF-M (as you mentioned).

then apply the patches from tf-m on top of it. If yes, vendors should be allowed to manually add patches on top like done by tf-m till we have a clear separation available.

Actually instead of patching a single file over and over from each single vendor, I would prefer to:

• Only apply patches from TF-M in the original psa_crypto_driver_wrappers.h. This would be the file being used when building with TF-M.
• Have an independent version of psa_crypto_driver_wrappers.h for each vendor. This would be used when building PSA Crypto together with Zephyr application (i.e. no TF-M).

The reason for this is mostly for portability of the patches in the future. I mean, what if in the future there is the need for another huge Mbed TLS/TF-PSA-Crypto version bump that introduces a lot of changes? Perhaps some of the patches won't apply there and in order to make things start working we'll need to wait for all the vendors to update their patches. Having independent files should help on this.

However this is also a topic for today's Security WG discussion.