How to solve the link error while enable both mbedTLS and TF-M crypto interfaces in NSPE
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
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
[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?
* Package those TF-M crypto header files into a interface library in NS CMake. * Link NS interface target to this interface library as a private library.
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.orgmailto: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.
[cid:image001.gif@01D9825C.7B0D4690]
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?
[cid:image002.gif@01D9825C.7B0D4690]
Best Regards, Poppy Wu
http://www.mxic.com.cnhttp://www.mxic.com.cn/-- TF-M mailing list -- tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.orgmailto: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
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?
* Package those TF-M crypto header files into a interface library in NS CMake. * Link NS interface target to this interface library as a private library.
Best regards, Hu Ziji
From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Monday, May 8, 2023 6:26 PM To: Edward Yang <edwardyang@mxic.com.cnmailto:edwardyang@mxic.com.cn>; Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto: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.orgmailto: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.
[cid:image001.gif@01D98260.21663D00]
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?
[cid:image002.gif@01D98260.21663D00]
Best Regards, Poppy Wu
http://www.mxic.com.cnhttp://www.mxic.com.cn/-- TF-M mailing list -- tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.orgmailto: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
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
2. 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 mailto:tf-m@lists.trustedfirmware.org > Sent: Tuesday, May 9, 2023 04:18 To: Kevin Townsend (kevin.townsend@linaro.org mailto:kevin.townsend@linaro.org ) <kevin.townsend@linaro.org mailto:kevin.townsend@linaro.org >; Edward Yang <edwardyang@mxic.com.cn mailto:edwardyang@mxic.com.cn >; Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org >; tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.com mailto: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?
* Package those TF-M crypto header files into a interface library in NS CMake. * Link NS interface target to this interface library as a private library.
Best regards,
Hu Ziji
From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org > Sent: Monday, May 8, 2023 6:26 PM To: Edward Yang <edwardyang@mxic.com.cn mailto:edwardyang@mxic.com.cn >; Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org mailto: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 mailto: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
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mxic.com.cn%2F&data=05%7C01%7Candrey.butok%40nxp.com%7C9afdbba01cf1409b05f908db5071d7b1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638192222102716473%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dFs1uH4%2Bgo5D6YLDCz55KyvdPduk2bS4BqDcuqJC0lc%3D&reserved=0 http://www.mxic.com.cn-- TF-M mailing list -- tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org mailto:tf-m-leave@lists.trustedfirmware.org
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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Tuesday, May 9, 2023 10:26 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Tuesday, May 9, 2023 04:18 To: Kevin Townsend (kevin.townsend@linaro.orgmailto:kevin.townsend@linaro.org) <kevin.townsend@linaro.orgmailto:kevin.townsend@linaro.org>; Edward Yang <edwardyang@mxic.com.cnmailto:edwardyang@mxic.com.cn>; Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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?
* Package those TF-M crypto header files into a interface library in NS CMake. * Link NS interface target to this interface library as a private library.
Best regards, Hu Ziji
From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Monday, May 8, 2023 6:26 PM To: Edward Yang <edwardyang@mxic.com.cnmailto:edwardyang@mxic.com.cn>; Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto: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.orgmailto: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.
[cid:image001.gif@01D98271.7F31B660]
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?
[cid:image002.gif@01D98271.7F31B660]
Best Regards, Poppy Wu
http://www.mxic.com.cnhttp://www.mxic.com.cn/-- TF-M mailing list -- tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.orgmailto: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
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 mailto:andrey.butok@nxp.com > Sent: Tuesday, May 9, 2023 12:13 To: Antonio De Angelis <Antonio.DeAngelis@arm.com mailto:Antonio.DeAngelis@arm.com >; tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.com mailto: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
2. 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 mailto:tf-m@lists.trustedfirmware.org > Sent: Tuesday, May 9, 2023 10:26 AM To: tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.com mailto: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 mailto:tf-m@lists.trustedfirmware.org > Sent: Tuesday, May 9, 2023 04:18 To: Kevin Townsend (kevin.townsend@linaro.org mailto:kevin.townsend@linaro.org ) <kevin.townsend@linaro.org mailto:kevin.townsend@linaro.org >; Edward Yang <edwardyang@mxic.com.cn mailto:edwardyang@mxic.com.cn >; Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org >; tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.com mailto: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?
* Package those TF-M crypto header files into a interface library in NS CMake. * Link NS interface target to this interface library as a private library.
Best regards,
Hu Ziji
From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org > Sent: Monday, May 8, 2023 6:26 PM To: Edward Yang <edwardyang@mxic.com.cn mailto:edwardyang@mxic.com.cn >; Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org mailto: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 mailto: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
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mxic.com.cn%2F&data=05%7C01%7Candrey.butok%40nxp.com%7Cfe2d97ec16cd4bd187bc08db50aa5d81%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638192464866654606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0Q0FO3jFsj4QNtvTl3M9blLxPshQLe2yZAdywVRHWuc%3D&reserved=0 http://www.mxic.com.cn-- TF-M mailing list -- tf-m@lists.trustedfirmware.org mailto:tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org mailto:tf-m-leave@lists.trustedfirmware.org
tf-m@lists.trustedfirmware.org
-
Andrej Butok -
Antonio De Angelis -
David Hu -
Edward Yang -
Kevin Townsend