With Zephyr, we ended up building MbedTLS as three distinct libraries (Zephyr originally produced a single library), linking the crypto library against TF-M, and the X.509 and TLS libraries against the NSPE (Zephyr), and making some changes to the cmake files to accommodate this partition scheme. This allowed TLS and X.509 certificate management on the NS side, with crypto operations handled by TF-M. It did require changes to the build system on both sides, though, but the exact solution will depend on what you're using on the NS side.

You'll also want to be using the very latest TF-M and MbedTLS code, since the 1.8.0 and 3.4.0 releases includes some changes to make this easier. Antonio from Arm may be able to comment on this, as author of some of those patches (if he's on this mailing list).

Best regards,

Kevin Townsend

On Mon, 8 May 2023 at 11:35, Edward Yang via TF-M <tf-m@lists.trustedfirmware.org> wrote:

Hi experts,

Recently we're developing an example demo based on TF-M, the application scenario is simplified as below.

MbedTLS module in NSPE is used to guarantee the secure communication with AWS cloud, while TF-M in SPE provides data encryption/decryption and
sensitive data storage services.

So both TF-M interfaces and mbedtls module are enabled on NSPE, there will be two implementations of PSA Crypto and this will result in a link error. The red box displays files with conflicts between mbedtls and TF-M,
which prevent the project from compiling. Can all TF-M code be converted into a lib to avoid linking issues? Or is there any other way to solve this problem?

Best Regards,
Poppy Wu

http://www.mxic.com.cn--
TF-M mailing list -- tf-m@lists.trustedfirmware.org
To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org