Just to a small addition on this: The approach that Kevin describes below (for example adopted in Zephyr) is what we have been recommending, i.e. not link with libmbedcrypto.a as both tfm_api_ns.a and libmbedcrypto.a would export the same PSA Crypto symbols.

 

In addition to this, since TF-M 1.8.0, by setting the compiler define CONFIG_TFM_CRYPTO_API_RENAME to 1 when building tfm_crypto_api.c in the NS interface, it’s possible to rename the TF-M crypto symbols to a name different than the standard. The aim for this would be to allow some increased flexibility for integrations that might require it.

 

Thanks, Antonio

 

From: David Hu via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Tuesday, May 9, 2023 04:18
To: Kevin Townsend (kevin.townsend@linaro.org) <kevin.townsend@linaro.org>; Edward Yang <edwardyang@mxic.com.cn>; Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Re: How to solve the link error while enable both mbedTLS and TF-M crypto interfaces in NSPE

 

[My previous reply was lost in the Internet 😊 ]

 

> Can all TF-M code be converted into a lib to avoid linking issues? Or is there any other way to solve this problem?

 

I’m not sure whether it can be general solution to solve this issue. NS interface implementation can vary according to NS application and RTOS. It is expected that NS developers/integrators implement their own NS interface code or modify the reference code.

Besides, NS and S might run on different arch/cpu with different configs.

It is more practical to export it as a source code reference.

 

Assumed that you are building NS separately from S build, can you please try if this workaround can help?

 

Best regards,

Hu Ziji

 

From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Monday, May 8, 2023 6:26 PM
To: Edward Yang <edwardyang@mxic.com.cn>; Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Re: How to solve the link error while enable both mbedTLS and TF-M crypto interfaces in NSPE

 

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



--

Thanks and best regards,

Kevin Townsend
Tech Lead - LITE, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs