Hi Antonio,

 

> could be specified through compile defines (MBEDTLS_PSA_CRYPTO_PLATFORM_FILE and MBEDTLS_PSA_CRYPTO_STRUCT_FILE), i.e. not relying on what is found on the include path

 

It creates even more problems for one project approach, as these global definitions have the same values for both MbedCrypto and TFM used it in one common project.

So we have to catch and workaround these differences manually.

 

The same named header files must have the same content, otherwise it creates constant issues for one project application.

Even for the multilibrary approach it is very confusing.

 

Thanks,

Andrej

 

From: Antonio De Angelis via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Tuesday, May 9, 2023 6:26 PM
To: 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

 

 

Hi Andrej,

 

This approach would make application code to be TF-M specific as applications following the spec are required to just #include “psa/crypto.h” to be able to use PSA Crypto APIs. With the structure you describe they would have to be written specifically for such TF-M’s include structure (i.e. #include psa/tfm/crypto.h).

 

Since TF-M 1.8.0/mbed TLS 3.4.0 the only differences in the headers are in crypto_struct and crypto_platform, and those headers could be specified through compile defines (MBEDTLS_PSA_CRYPTO_PLATFORM_FILE and MBEDTLS_PSA_CRYPTO_STRUCT_FILE), i.e. not relying on what is found on the include path.

 

Thanks, Antonio

 

From: Andrej Butok <andrey.butok@nxp.com>
Sent: Tuesday, May 9, 2023 12:13
To: Antonio De Angelis <Antonio.DeAngelis@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: RE: [TF-M] Re: How to solve the link error while enable both mbedTLS and TF-M crypto interfaces in NSPE

 

Hi Antonio,

 

In our SDK we may not use the multiple-library approach used by Upstream TFM.

So, we are compiling MbedCrypto and TFM in one Secure project (not separate libraries).

To avoid the path conflicts, we have applied the following changes:

  1. The conflict name files were moved from the “psa” to “psa/tfm” folder. Moved files:

psa/tfm/crypto.h

psa/tfm/crypto_compat.h

psa/tfm/crypto_extra.h

psa/tfm/crypto_platform.h

psa/tfm/crypto_sizes.h

psa/tfm/crypto_struct.h

psa/tfm/crypto_types.h

psa/tfm/crypto_values.h

  1. Changed include “psa” to “psa/tfm” in TFM sources were it is required.

 

Can something like this applied to the Upstream TFM project?

 

Best Regards,

Andrej Butok

NXP Semiconductors

 

From: Antonio De Angelis via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Tuesday, May 9, 2023 10:26 AM
To: 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

 

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