MbedTLS/TF-M usability improvements for PSA APIs

[rajkan01]

Linked PRs

• Patch: Align MbedTLS PSA headers with TFM PSA headers mbedtls#43
• Patchset: Align TFM to mbedTLS trusted-firmware-m#92

Description

Previously, Zephyr's mbedtls module's cmake build created a single static library, rather than the collection of libraries (mbedtls, mbedcrypto, and mbedx509) that upstream mbedTLS cmake provides.

To give better control at link time to choose the required libraries to link in, this commit updates the Zephyr MbedTLS module to also define three distinct libraries rather than a single static MbedTLS library.

One benefit of the three library approach is that if mbedTLS is used in Zephyr in the the non-secure application in addition to TFM's PSA Crypto API on the secure side with TF-M, PSA API calls on the non-secure side will be redirected to the TFM PSA implementation, and the mbedcrypto library will only be linked to the secure (TF-M) binary, with the mbedtls and mbedx509 libraries linked against the non-secure (Zephyr) binary, enabling TLS calls to PSA crypto to be redirected to mbedcrypto in the secure partition and avoiding function duplication in the non-secure binary.

Additional Changes

Re-commits the psa_crypto sample, which had to be removed during the TF-M 1.7.0 update due to unresolvable linker issues with MbedTLS as a single static library.

Fixes #56995

[zephyrbot]

The following west manifest projects have been modified in this Pull Request:

Name	Old Revision	New Revision	Diff
mbedtls	zephyrproject-rtos/mbedtls@4e1f66d	zephyrproject-rtos/mbedtls@6e7841e (zephyr)	zephyrproject-rtos/mbedtls@4e1f66df..6e7841e5
trusted-firmware-m	zephyrproject-rtos/trusted-firmware-m@8209cb2	zephyrproject-rtos/trusted-firmware-m@79a6115 (master)	zephyrproject-rtos/trusted-firmware-m@8209cb2e..79a6115d

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[ceolin]

1c1dd384b877bf6b3fa66bfb9ba85c2528994c5d -> can we make this include path automatic when CONFIG_MBEDTLS is selected ? That is breaking the current usage and and it is not the common pattern on Zephyr AFAIR.

Other than that looks good to me.

[microbuilder]

1c1dd384b877bf6b3fa66bfb9ba85c2528994c5d -> can we make this include path automatic when CONFIG_MBEDTLS is selected ? That is breaking the current usage and and it is not the common pattern on Zephyr AFAIR.

Other than that looks good to me.

Thanks for the feedback, Flavio. There is a precedent for this here, for example: https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/lib/sockets/CMakeLists.txt#L35 ... but can you point to an example of what you'd like to see here instead?

[microbuilder]

@tejlmand Do you have time to look at some of the cmake changes in this patchset, to get these in before feature freeze Friday, and maybe make some suggestions for Raj to update ASAP?

Any chance you're free for the security call today (16:00 in Norway) if we discuss this?

[joerchan]

I want to be stricter in what are exposed in interface include paths.

sha512.h could be define by other modules for example.
mbedtls/sh512.h is very clear.

[rajkan01]

I want to be stricter in what are exposed in interface include paths.

sha512.h could be define by other modules for example. mbedtls/sh512.h is very clear.

@ joerchan I would say this is already taken care of in the mbedTLS sha512.h file if the user defines this flag: https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/include/mbedtls/sha512.h#L40.

Please let me know if there is any other mbedTLS header file that may have a problem like that.

[d3zd3z]

The changes look good, but we'll have to wait for the TF-M and mbedtls changes to merge, and update the reference. I'll approve, as there appears to be a DNM on it.

[joerchan]

I want to be stricter in what are exposed in interface include paths.
sha512.h could be define by other modules for example. mbedtls/sh512.h is very clear.

@ joerchan I would say this is already taken care of in the mbedTLS sha512.h file if the user defines this flag: https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/include/mbedtls/sha512.h#L40.

Please let me know if there is any other mbedTLS header file that may have a problem like that.

You misunderstood me, I'm not talking about mbedtls ALT headers for sh512. I'm talking about other modules having their own sh512 header.

In zephyr you can include:
<tinycrypt/sha512.h>
<mbedtls/sha512.h>
If you include:
<sha512.h>
Then which one would you get?

The hostap module (Wi-FI) for example has a sha512.h header file that will be included like "sha512.h". Now I have to make sure that correct sha header file is included by looking at header file path order.

So I don't want "include/mbedtls" and "include/psa" on the include path for this reason.

[rajkan01]

I want to be stricter in what are exposed in interface include paths.
sha512.h could be define by other modules for example. mbedtls/sh512.h is very clear.

@ joerchan I would say this is already taken care of in the mbedTLS sha512.h file if the user defines this flag: https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/include/mbedtls/sha512.h#L40.
Please let me know if there is any other mbedTLS header file that may have a problem like that.

You misunderstood me, I'm not talking about mbedtls ALT headers for sh512. I'm talking about other modules having their own sh512 header.

In zephyr you can include: <tinycrypt/sha512.h> <mbedtls/sha512.h> If you include: <sha512.h> Then which one would you get?

The hostap module (Wi-FI) for example has a sha512.h header file that will be included like "sha512.h". Now I have to make sure that correct sha header file is included by looking at header file path order.

So I don't want "include/mbedtls" and "include/psa" on the include path for this reason.

Sorry, as you said, I misunderstood. I made the library include path changes pushed here already; please review and approve if you are okay with the final changes.

[joerchan]

Thanks @rajkan01 Looks good to me now.

[d3zd3z]

Looks good, as long as CI passes.