- TF-M - lists.trustedfirmware.org

Re: [TF-M] Questions on Musca-B1 SE implementation - code size analysis

by Antonio De Angelis

Hi Suresh/Raef, There is no problem in evaluating and reviewing fixes and optimisations to the CC runtime hosted in TF-M. I will have a look into this and sync up with @Raef Coles as well regarding the possible solution that he mentions below. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: Tuesday, July 6, 2021 5:15 PM To: David Hu <David.Hu(a)arm.com>; Mark Horvath <Mark.Horvath(a)arm.com>; Suresh.Marisetty(a)infineon.com Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Questions on Musca-B1 SE implementation - code size analysis Hey Suresh I've had a look into this, and it seems to be a limitation of the cryptocell runtime library. Profile medium enables MBEDTLS_ECDSA_C, which then causes cryptocell's accelerator config to set MBEDTLS_ECDSA_VERIFY_ALT, which are both working as expected. The problem is that the runtime library doesn't use the MBEDTLS_ECP_DP_SECP521R1_ENABLED define (or any other define) to conditionally enable function pointers in the lists used for selecting ECC functions (see cc_ecpki_info.c), so the linker cant optimize those functions out of the final image. Actually fixing this issue probably isn't too much of a problem, but there is an underlying problem that currently the runtime library is effectively unmaintained, and I'm not sure that TF-M can commit to fixing all of the issues in it. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Suresh Marisetty via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 06 July 2021 15:49 To: David Hu; Mark Horvath Cc: nd; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Questions on Musca-B1 SE implementation - code size analysis Hi David, One of our observation is that for Medium profile, some ciphers are disabled in the medcrypto portion through the config file (tfm_mbedcrypto_config_profile_medium.h). However, the CC312 components appears to be generating libraries that are disabled in mbedcrypto. One such example is the object file: cc_ecpki_domain_secp521r1.o generated for medium profile. Wondering if this is expected or just an overlooked escape. I am assuming all ciphers not enabled in mbedcrypto portion should NOT have corresponding cc312 components, to help optimize the image sizes. thanks Suresh Marisetty Infineon Semiconductor Corporation From: David Hu <David.Hu(a)arm.com> Sent: Sunday, July 4, 2021 11:37 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com>; Mark Horvath <Mark.Horvath(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: RE: Questions on Musca-B1 SE implementation - code size analysis Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, 1. Please check t Profile Medium and Profile Large design documents below. The ciphers supported are listed in the document. Profile Medium: https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/profi… Profile Large: https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/profi… 1. I don’t think the software countermeasures against physical attacks are enabled in Musca-B1 SE, by default. Mark, please correct me if I misunderstand it. TF-M implements a Fault Inject Hardening (FIH) library as software countermeasure to mitigate physical attacks. FIH is enabled as Medium Profile in Profile Large by default. You can set `TFM_FIH_PROFILE` as OFF to disable FIH features. FIH is not implemented by mebd TLS or CC312. It consists of protections of TF-M SPM critical routine and platform specific isolation configuration. Please check FIH design document: https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/tfm_p… Compared to Profile Medium, Profile Large enables more cryptographic algorithms support and FIH library. It may also include more configurations of higher isolation. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: Sunday, July 4, 2021 2:26 AM To: Mark Horvath <Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Questions on Musca-B1 SE implementation - code size analysis Hi Mark, Wondering if someone can provide more visibility in the following in regards to the SE build with profile medium and large: 1. What ciphers are supported in medium vs. large (I see the size of the code bloats up almost twice from 30 to 60K approx) – observation from size of libmbedcrypto and libcrypto_service_cc312 – any clear documentation on this or a link would be helpful (besides code review) 2. When the SE is built for the large profile, assume it also includes “Software countermeasures against physical attacks” since it is offloading to the CC-312 * Is there a way to build the large profile without physical attack counter-measures? * While library are these countermeasures implemented in (libmbed or lib_cc312)? 1. On our initial analysis, for a medium profile these two libraries appears to be 30K-33K in size each and is this in the right ballpark? (with minsizerel) I assume the code size increase is due to additional cipher support + physical attack countermeasures. Correct me otherwise. thanks Suresh Marisetty Infineon Semiconductor Corporation From: Mark Horvath <Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com>> Sent: Friday, May 14, 2021 5:30 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: Questions on Musca-B1 SE implementation Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, Yes, by default the cc312 acceleration is turned on at build time for SE, and the algorithms will be handled by HW instead of the SW implementation. If you would like to use SW crypto instead you can pass the HW_ACCELERATOR="OFF" flag to cmake when building the SE TF-M instance. And here are the TF-M image sizes as of now with GCC in release mode: SE: ~185 KiB code flash and ~63 KiB RAM Host: ~22 KiB code flash and ~16 KiB RAM (a few more KiB needed for the images in flash for image header and trailer if loaded by mcuboot) Best regards, Mark ________________________________ From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Sent: Thursday, May 13, 2021 5:26 AM To: Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com> <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; Mark Horvath <Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Questions on Musca-B1 SE implementation Hi @Mark Horvath<mailto:Mark.Horvath@arm.com>, Could you please help take a look at the following questions about Musca-B1 SE? Thanks 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: Thursday, May 13, 2021 6:04 AM To: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Questions on Musca-B1 SE implementation Hi Tamas, The following is good information. A few questions: 1. Is it correct to state that for the SE, the PSA RoT services do not have any software Crypto implementation, but leverage from CC-312? 2. What is the size of the TFM on the host (M33) with only PSA RoT service proxy with redirection to SE 3. Just trying to understand the TFM image size requirements on M33 vs. SE 4. How much of the Flash region/code Executed In Place vs. execution out of SRAM (XIP) thanks Suresh Marisetty Infineon Semiconductor Corporation From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>> Sent: Friday, April 30, 2021 12:40 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Questions on Musca-B1 SE implementation Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, Here is a link how to build images to Musca-B1 SE: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e… I have built with GCC and MinSizeRel build type: Profile Medium: Memory region Used Size Region Size %age Used FLASH: 101464 B 381 KB 26.01% RAM: 61304 B 64 KB 93.54% [100%] Built target tfm_s Profile Large: Memory region Used Size Region Size %age Used FLASH: 170448 B 381 KB 43.69% RAM: 62980 B 64 KB 96.10% [ 97%] Built target tfm_s The profiles means different capabilities of TF-M, they were introduced to support constrained devices as well, with limited capability. There is a detailed description about the profiles here: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn… BR, Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: 2021. április 29., csütörtök 21:49 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Questions on Musca-B1 SE implementation I am following up on a question that came up on the TFM Core and MCUBoot image sizes that is built for SE on Musca-B1. We are trying to figure out the resource requirements for SE, to be able to host the TF-M as suggested in the slides below. Wondering if anyone throw more light on the RAM/FLASH requirements for it. Also, does the TFM profile small/medium/large map to this at all or is it different from them. Also, what’s are the estimated latencies of boot on SE with all the Flash accesses, etc. https://www.trustedfirmware.org/docs/Musca-B1-Secure-Enclave-Solution.pdf https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e… Any info on this would be appreciated. thanks Suresh Marisetty Infineon Semiconductor Corporation -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 4 months

2
1
0 0

Re: [TF-M] Questions on Musca-B1 SE implementation - code size analysis

by Raef Coles

Hey Suresh I've had a look into this, and it seems to be a limitation of the cryptocell runtime library. Profile medium enables MBEDTLS_ECDSA_C, which then causes cryptocell's accelerator config to set MBEDTLS_ECDSA_VERIFY_ALT, which are both working as expected. The problem is that the runtime library doesn't use the MBEDTLS_ECP_DP_SECP521R1_ENABLED define (or any other define) to conditionally enable function pointers in the lists used for selecting ECC functions (see cc_ecpki_info.c), so the linker cant optimize those functions out of the final image. Actually fixing this issue probably isn't too much of a problem, but there is an underlying problem that currently the runtime library is effectively unmaintained, and I'm not sure that TF-M can commit to fixing all of the issues in it. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Suresh Marisetty via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 06 July 2021 15:49 To: David Hu; Mark Horvath Cc: nd; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Questions on Musca-B1 SE implementation - code size analysis Hi David, One of our observation is that for Medium profile, some ciphers are disabled in the medcrypto portion through the config file (tfm_mbedcrypto_config_profile_medium.h). However, the CC312 components appears to be generating libraries that are disabled in mbedcrypto. One such example is the object file: cc_ecpki_domain_secp521r1.o generated for medium profile. Wondering if this is expected or just an overlooked escape. I am assuming all ciphers not enabled in mbedcrypto portion should NOT have corresponding cc312 components, to help optimize the image sizes. thanks Suresh Marisetty Infineon Semiconductor Corporation From: David Hu <David.Hu(a)arm.com> Sent: Sunday, July 4, 2021 11:37 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com>; Mark Horvath <Mark.Horvath(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: RE: Questions on Musca-B1 SE implementation - code size analysis Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, 1. Please check t Profile Medium and Profile Large design documents below. The ciphers supported are listed in the document. Profile Medium: https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/profi… Profile Large: https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/profi… 1. I don’t think the software countermeasures against physical attacks are enabled in Musca-B1 SE, by default. Mark, please correct me if I misunderstand it. TF-M implements a Fault Inject Hardening (FIH) library as software countermeasure to mitigate physical attacks. FIH is enabled as Medium Profile in Profile Large by default. You can set `TFM_FIH_PROFILE` as OFF to disable FIH features. FIH is not implemented by mebd TLS or CC312. It consists of protections of TF-M SPM critical routine and platform specific isolation configuration. Please check FIH design document: https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/tfm_p… Compared to Profile Medium, Profile Large enables more cryptographic algorithms support and FIH library. It may also include more configurations of higher isolation. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: Sunday, July 4, 2021 2:26 AM To: Mark Horvath <Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Questions on Musca-B1 SE implementation - code size analysis Hi Mark, Wondering if someone can provide more visibility in the following in regards to the SE build with profile medium and large: 1. What ciphers are supported in medium vs. large (I see the size of the code bloats up almost twice from 30 to 60K approx) – observation from size of libmbedcrypto and libcrypto_service_cc312 – any clear documentation on this or a link would be helpful (besides code review) 2. When the SE is built for the large profile, assume it also includes “Software countermeasures against physical attacks” since it is offloading to the CC-312 * Is there a way to build the large profile without physical attack counter-measures? * While library are these countermeasures implemented in (libmbed or lib_cc312)? 1. On our initial analysis, for a medium profile these two libraries appears to be 30K-33K in size each and is this in the right ballpark? (with minsizerel) I assume the code size increase is due to additional cipher support + physical attack countermeasures. Correct me otherwise. thanks Suresh Marisetty Infineon Semiconductor Corporation From: Mark Horvath <Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com>> Sent: Friday, May 14, 2021 5:30 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: Questions on Musca-B1 SE implementation Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, Yes, by default the cc312 acceleration is turned on at build time for SE, and the algorithms will be handled by HW instead of the SW implementation. If you would like to use SW crypto instead you can pass the HW_ACCELERATOR="OFF" flag to cmake when building the SE TF-M instance. And here are the TF-M image sizes as of now with GCC in release mode: SE: ~185 KiB code flash and ~63 KiB RAM Host: ~22 KiB code flash and ~16 KiB RAM (a few more KiB needed for the images in flash for image header and trailer if loaded by mcuboot) Best regards, Mark ________________________________ From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Sent: Thursday, May 13, 2021 5:26 AM To: Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com> <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; Mark Horvath <Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Questions on Musca-B1 SE implementation Hi @Mark Horvath<mailto:Mark.Horvath@arm.com>, Could you please help take a look at the following questions about Musca-B1 SE? Thanks 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: Thursday, May 13, 2021 6:04 AM To: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Questions on Musca-B1 SE implementation Hi Tamas, The following is good information. A few questions: 1. Is it correct to state that for the SE, the PSA RoT services do not have any software Crypto implementation, but leverage from CC-312? 2. What is the size of the TFM on the host (M33) with only PSA RoT service proxy with redirection to SE 3. Just trying to understand the TFM image size requirements on M33 vs. SE 4. How much of the Flash region/code Executed In Place vs. execution out of SRAM (XIP) thanks Suresh Marisetty Infineon Semiconductor Corporation From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>> Sent: Friday, April 30, 2021 12:40 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Questions on Musca-B1 SE implementation Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, Here is a link how to build images to Musca-B1 SE: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e… I have built with GCC and MinSizeRel build type: Profile Medium: Memory region Used Size Region Size %age Used FLASH: 101464 B 381 KB 26.01% RAM: 61304 B 64 KB 93.54% [100%] Built target tfm_s Profile Large: Memory region Used Size Region Size %age Used FLASH: 170448 B 381 KB 43.69% RAM: 62980 B 64 KB 96.10% [ 97%] Built target tfm_s The profiles means different capabilities of TF-M, they were introduced to support constrained devices as well, with limited capability. There is a detailed description about the profiles here: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn… BR, Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: 2021. április 29., csütörtök 21:49 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Questions on Musca-B1 SE implementation I am following up on a question that came up on the TFM Core and MCUBoot image sizes that is built for SE on Musca-B1. We are trying to figure out the resource requirements for SE, to be able to host the TF-M as suggested in the slides below. Wondering if anyone throw more light on the RAM/FLASH requirements for it. Also, does the TFM profile small/medium/large map to this at all or is it different from them. Also, what’s are the estimated latencies of boot on SE with all the Flash accesses, etc. https://www.trustedfirmware.org/docs/Musca-B1-Secure-Enclave-Solution.pdf https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e… Any info on this would be appreciated. thanks Suresh Marisetty Infineon Semiconductor Corporation

4 years, 4 months

1
0
0 0

Re: [TF-M] Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder?

by Anton Komlev

Hi Poppy, Platform folder represents a HW integration layer. What kind of use case you have in mind to call the secure services from there? Thanks, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Tuesday, July 6, 2021 9:30 AM To: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: [TF-M] Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder? Hi experts, The tf-m project includes secure_fw and paltform these two folders, I want to know whether the codes in platform folder are allowed to call secure services directly? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 4 months

1
0
0 0

Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder?

by Edward Yang

Hi experts, The tf-m project includes secure_fw and paltform these two folders, I want to know whether the codes in platform folder are allowed to call secure services directly? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 4 months

1
0
0 0

Technical Forum call - July 8

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 8 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 4 months

1
0
0 0

Questions on Musca-B1 SE implementation - code size analysis

by Suresh.Marisetty＠infineon.com

Hi Mark, Wondering if someone can provide more visibility in the following in regards to the SE build with profile medium and large: 1. What ciphers are supported in medium vs. large (I see the size of the code bloats up almost twice from 30 to 60K approx) – observation from size of libmbedcrypto and libcrypto_service_cc312 – any clear documentation on this or a link would be helpful (besides code review) 2. When the SE is built for the large profile, assume it also includes “Software countermeasures against physical attacks” since it is offloading to the CC-312 * Is there a way to build the large profile without physical attack counter-measures? * While library are these countermeasures implemented in (libmbed or lib_cc312)? 3. On our initial analysis, for a medium profile these two libraries appears to be 30K-33K in size each and is this in the right ballpark? (with minsizerel) I assume the code size increase is due to additional cipher support + physical attack countermeasures. Correct me otherwise. thanks Suresh Marisetty Infineon Semiconductor Corporation From: Mark Horvath <Mark.Horvath(a)arm.com> Sent: Friday, May 14, 2021 5:30 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: Questions on Musca-B1 SE implementation Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, Yes, by default the cc312 acceleration is turned on at build time for SE, and the algorithms will be handled by HW instead of the SW implementation. If you would like to use SW crypto instead you can pass the HW_ACCELERATOR="OFF" flag to cmake when building the SE TF-M instance. And here are the TF-M image sizes as of now with GCC in release mode: SE: ~185 KiB code flash and ~63 KiB RAM Host: ~22 KiB code flash and ~16 KiB RAM (a few more KiB needed for the images in flash for image header and trailer if loaded by mcuboot) Best regards, Mark ________________________________ From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Sent: Thursday, May 13, 2021 5:26 AM To: Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com> <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; Mark Horvath <Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Questions on Musca-B1 SE implementation Hi @Mark Horvath<mailto:Mark.Horvath@arm.com>, Could you please help take a look at the following questions about Musca-B1 SE? Thanks 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: Thursday, May 13, 2021 6:04 AM To: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Questions on Musca-B1 SE implementation Hi Tamas, The following is good information. A few questions: 1. Is it correct to state that for the SE, the PSA RoT services do not have any software Crypto implementation, but leverage from CC-312? 2. What is the size of the TFM on the host (M33) with only PSA RoT service proxy with redirection to SE 3. Just trying to understand the TFM image size requirements on M33 vs. SE 4. How much of the Flash region/code Executed In Place vs. execution out of SRAM (XIP) thanks Suresh Marisetty Infineon Semiconductor Corporation From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>> Sent: Friday, April 30, 2021 12:40 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Questions on Musca-B1 SE implementation Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, Here is a link how to build images to Musca-B1 SE: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e… I have built with GCC and MinSizeRel build type: Profile Medium: Memory region Used Size Region Size %age Used FLASH: 101464 B 381 KB 26.01% RAM: 61304 B 64 KB 93.54% [100%] Built target tfm_s Profile Large: Memory region Used Size Region Size %age Used FLASH: 170448 B 381 KB 43.69% RAM: 62980 B 64 KB 96.10% [ 97%] Built target tfm_s The profiles means different capabilities of TF-M, they were introduced to support constrained devices as well, with limited capability. There is a detailed description about the profiles here: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn… BR, Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: 2021. április 29., csütörtök 21:49 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Questions on Musca-B1 SE implementation I am following up on a question that came up on the TFM Core and MCUBoot image sizes that is built for SE on Musca-B1. We are trying to figure out the resource requirements for SE, to be able to host the TF-M as suggested in the slides below. Wondering if anyone throw more light on the RAM/FLASH requirements for it. Also, does the TFM profile small/medium/large map to this at all or is it different from them. Also, what’s are the estimated latencies of boot on SE with all the Flash accesses, etc. https://www.trustedfirmware.org/docs/Musca-B1-Secure-Enclave-Solution.pdf https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e… Any info on this would be appreciated. thanks Suresh Marisetty Infineon Semiconductor Corporation

4 years, 4 months

1
0
0 0

Re: [TF-M] How to build psa-arch-tests to debug mode with debug symbols

by Summer Qin

Hi Matt, Do you want to just build psa-arch tests alone? I check the psa-arch-tests build command documentation (api-tests/dev_apis/README.md), it doesn't mention '-DCMAKE_BUILD_TYPE'. Usually, we build it from TF-M side. It has debug symbols if you build from TF-M with '-DCMAKE_BUILD_TYPE=Debug'. Also, you can build debug variant through the DS-5 environment. It also works. BR, Summer ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Matt via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, July 1, 2021 9:11 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] How to build psa-arch-tests to debug mode with debug symbols Hi All experts, I want to build psa-arch-tests to debug mode with debug symbols. I have tried the following command, but it does not take effect. cmake ../ -G"<generator_name>" -DTARGET=<platform_name> -DCPU_ARCH=<cpu_architecture_version> -DCMAKE_BUILD_TYPE=Debug -DSUITE=<suite_name> -DPSA_INCLUDE_PATHS="<include_path1>;<include_path2>;...;<include_pathn>" cmake --build . How can I build psa-arch-tests to debug mode with debug symbols? Thanks, Matt

4 years, 4 months

2
2
0 0

How to build psa-arch-tests to debug mode with debug symbols

by Matt

Hi All experts, I want to build psa-arch-tests to debug mode with debug symbols. I have tried the following command, but it does not take effect. cmake ../ -G"<generator_name>" -DTARGET=<platform_name> -DCPU_ARCH=<cpu_architecture_version> -DCMAKE_BUILD_TYPE=Debug -DSUITE=<suite_name> -DPSA_INCLUDE_PATHS="<include_path1>;<include_path2>;...;<include_pathn>" cmake --build . How can I build psa-arch-tests to debug mode with debug symbols? Thanks, Matt

4 years, 4 months

1
0
0 0

[Doc]Update sphinx to 2.0.1

by Summer Qin

Hi, To better maintain tf-m documentation, we plan to enable 'turn warnings into errors' in documentation HTML generation. The patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10424> is on review now. One note is that sphinx should be updated to 2.0.1, otherwise there will be some 'duplicate label' warnings, which will fail documentation generation. Best Regards, Summer

4 years, 4 months

1
0
0 0

Re: [TF-M] Static check framework for TF-M

by Gyorgy Szing

Hi, Please consider separating the configuration files from the scripts/tools. That would enable re-using the scripts in other projects. I.e. if the .clang-format file lives in the tf-m repo, then the script running clang-format could be used with multiple repositories. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Salome Thirot via TF-M Sent: 28 June 2021 11:42 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Static check framework for TF-M Hi all, Hugo L'Hostis and I have written a series of patches to enable various checks that can be done locally before committing the code, they will be added in the tf-m-tools repository. The patches are the following, any comment is welcome: cppcheck: https://review.trustedfirmware.org/c/TF-M/tf-m-tools/+/10009/8 clang-format: https://review.trustedfirmware.org/c/TF-M/tf-m-tools/+/10463/2 copyright headers: https://review.trustedfirmware.org/c/TF-M/tf-m-tools/+/10464/2 Regards, Salome

4 years, 4 months

1
0
0 0

Re: [TF-M] TFM psa-arch-tests using mbedtls

by Summer Qin

Hi Matt, Thanks for your nice feedback! Yes, your understanding is correct. We had discussed this issue in mbedtls github, you can refer the details here<https://github.com/ARMmbed/mbed-crypto/issues/175>. We also feedback it to psa arch test team, hope they can fix it soon. Again, thanks for pointing it out : ) BR, Summer ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Matt via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, June 30, 2021 10:33 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TFM psa-arch-tests using mbedtls Hi all TFM experts, 近期我在移植psa-arch-tests到我们的板子上，想看下functional api的测试结果。 TFM用的是1.1的版本，psa-arch-tests 用的是master分支，代码取到 1f96094734897674fa907fba2050bc52e1b3d0fe 这个commit. mbedtls使用的分支是2.23.0。在测试crypto 的 c021 ，即psa_key_derivation_output_key的测试时，看结果是FAIL的，看了下c021下的test_data.h，check1数组前面两项的信息如下， static const test_data check1[] = { {"Test psa_key_derivation_output_key - Key\n", PSA_KEY_TYPE_DERIVE, {0x49, 0x8E, 0xC7, 0x7D, 0x01, 0x95, 0x0D, 0x94, 0x2C, 0x16, 0xA5, 0x3E, 0x99, 0x5F, 0xC9, 0x77}, AES_16B_KEY_SIZE, PSA_KEY_USAGE_DERIVE, PSA_ALG_KEY_AGREEMENT(PSA_ALG_ECDH, PSA_ALG_HKDF(PSA_ALG_SHA_256)), PSA_KEY_DERIVATION_INPUT_SECRET, 32, {0}, 0, PSA_KEY_TYPE_AES, BYTES_TO_BITS(AES_32B_KEY_SIZE), PSA_KEY_USAGE_EXPORT, PSA_ALG_CTR, PSA_SUCCESS }, {"Test psa_key_derivation_output_key - Info\n", PSA_KEY_TYPE_DERIVE, {0x49, 0x8E, 0xC7, 0x7D, 0x01, 0x95, 0x0D, 0x94, 0x2C, 0x16, 0xA5, 0x3E, 0x99, 0x5F, 0xC9, 0x77}, AES_16B_KEY_SIZE, PSA_KEY_USAGE_DERIVE, PSA_ALG_KEY_AGREEMENT(PSA_ALG_ECDH, PSA_ALG_HKDF(PSA_ALG_SHA_256)), PSA_KEY_DERIVATION_INPUT_INFO, 32, "This is the info", 16, PSA_KEY_TYPE_AES, BYTES_TO_BITS(AES_32B_KEY_SIZE), PSA_KEY_USAGE_EXPORT, PSA_ALG_CTR, PSA_SUCCESS }, 秘钥派生的算法使用的是PSA_ALG_HKDF(PSA_ALG_SHA_256)，在mbedtls库中，使用HKDF算法时，在读取输出即调用 psa_key_derivation_output_bytes或者psa_key_derivation_output_key时，内部调用到 psa_key_derivation_hkdf_read时会检查两个必要的条件，一个是是否已输入key，一个是是否已输入info，如果只输入一个，就返回BAD_STATE。但是上面 check1的前两项都是只输入一个项， check1的第一项是只输入key, 第二项是只输入info，所以应该返回 BAD_STATE，不应该是 PSA_SUCCESS。在psa arch tests crypto的 c020测试中早期的版本也有类似的问题，不过最新的代码已变化为输入key和info 这两个量后才去读取派生的结果。在网上也了解了下HKDF的介绍，也提到了key和info这两个必要的输入： [cid:20571824$1$17a5ac32875$Coremail$majun.china$126.com] 如果使用TFM默认的 mbedtls库，crypto的这个测试应该是通不过的，因为mbedtls最新的版本，在读取派生结果时，依然要检测key和info是否都已输入。请帮check下，是我理解的不对，还是crypto 的 c021 这个case不适合mbedtls软算法库。以上信息，感谢TFM的各位专家，期盼你们的回复谢谢！

4 years, 4 months

2
1
0 0

TFM psa-arch-tests using mbedtls

by Matt

Hi all TFM experts, 近期我在移植psa-arch-tests到我们的板子上，想看下functional api的测试结果。 TFM用的是1.1的版本，psa-arch-tests 用的是master分支，代码取到 1f96094734897674fa907fba2050bc52e1b3d0fe 这个commit. mbedtls使用的分支是2.23.0。在测试crypto 的 c021 ，即psa_key_derivation_output_key的测试时，看结果是FAIL的，看了下c021下的test_data.h，check1数组前面两项的信息如下， static const test_data check1[] = { {"Test psa_key_derivation_output_key - Key\n", PSA_KEY_TYPE_DERIVE, {0x49, 0x8E, 0xC7, 0x7D, 0x01, 0x95, 0x0D, 0x94, 0x2C, 0x16, 0xA5, 0x3E, 0x99, 0x5F, 0xC9, 0x77}, AES_16B_KEY_SIZE, PSA_KEY_USAGE_DERIVE, PSA_ALG_KEY_AGREEMENT(PSA_ALG_ECDH, PSA_ALG_HKDF(PSA_ALG_SHA_256)), PSA_KEY_DERIVATION_INPUT_SECRET, 32, {0}, 0, PSA_KEY_TYPE_AES, BYTES_TO_BITS(AES_32B_KEY_SIZE), PSA_KEY_USAGE_EXPORT, PSA_ALG_CTR, PSA_SUCCESS }, {"Test psa_key_derivation_output_key - Info\n", PSA_KEY_TYPE_DERIVE, {0x49, 0x8E, 0xC7, 0x7D, 0x01, 0x95, 0x0D, 0x94, 0x2C, 0x16, 0xA5, 0x3E, 0x99, 0x5F, 0xC9, 0x77}, AES_16B_KEY_SIZE, PSA_KEY_USAGE_DERIVE, PSA_ALG_KEY_AGREEMENT(PSA_ALG_ECDH, PSA_ALG_HKDF(PSA_ALG_SHA_256)), PSA_KEY_DERIVATION_INPUT_INFO, 32, "This is the info", 16, PSA_KEY_TYPE_AES, BYTES_TO_BITS(AES_32B_KEY_SIZE), PSA_KEY_USAGE_EXPORT, PSA_ALG_CTR, PSA_SUCCESS }, 秘钥派生的算法使用的是PSA_ALG_HKDF(PSA_ALG_SHA_256)，在mbedtls库中，使用HKDF算法时，在读取输出即调用 psa_key_derivation_output_bytes或者psa_key_derivation_output_key时，内部调用到 psa_key_derivation_hkdf_read时会检查两个必要的条件，一个是是否已输入key，一个是是否已输入info，如果只输入一个，就返回BAD_STATE。但是上面 check1的前两项都是只输入一个项， check1的第一项是只输入key, 第二项是只输入info，所以应该返回 BAD_STATE，不应该是 PSA_SUCCESS。在psa arch tests crypto的 c020测试中早期的版本也有类似的问题，不过最新的代码已变化为输入key和info 这两个量后才去读取派生的结果。在网上也了解了下HKDF的介绍，也提到了key和info这两个必要的输入：如果使用TFM默认的 mbedtls库，crypto的这个测试应该是通不过的，因为mbedtls最新的版本，在读取派生结果时，依然要检测key和info是否都已输入。请帮check下，是我理解的不对，还是crypto 的 c021 这个case不适合mbedtls软算法库。以上信息，感谢TFM的各位专家，期盼你们的回复谢谢！

4 years, 4 months

1
0
0 0

Static check framework for TF-M

by Salome Thirot

Hi all, Hugo L'Hostis and I have written a series of patches to enable various checks that can be done locally before committing the code, they will be added in the tf-m-tools repository. The patches are the following, any comment is welcome: cppcheck: https://review.trustedfirmware.org/c/TF-M/tf-m-tools/+/10009/8 clang-format: https://review.trustedfirmware.org/c/TF-M/tf-m-tools/+/10463/2 copyright headers: https://review.trustedfirmware.org/c/TF-M/tf-m-tools/+/10464/2 Regards, Salome

4 years, 4 months

1
0
0 0

Re: [TF-M] Remove Customized Region Name Prefix in Linker Scripts

by Andrej Butok

This is the "good practice" to add prefixes to global names. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Xinyu Zhang via TF-M Sent: Thursday, June 24, 2021 12:00 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Remove Customized Region Name Prefix in Linker Scripts Hi, The existing linker definitions abuse prefixes such as ER_ and TFM_. Some names do not have a clear scope, which reduces the readability. Here are some patches to address the problem: * Patch 10383 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr ustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F10383&data=04%7C01 %7Candrey.butok%40nxp.com%7C8c57174d86d447802a4908d936f6d729%7C686ea1d3bc2b4 c6fa92cd99c5c301635%7C0%7C0%7C637601256068960339%7CUnknown%7CTWFpbGZsb3d8eyJ WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata =G8Jf5YT4mptpeBUw8U7YkVbSKGvgXXtC3G8wRBqbJvY%3D&reserved=0> : TFM_UNPRIV_CODE --> UNPRIV_CODE * Patch 10384 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr ustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F10384&data=04%7C01 %7Candrey.butok%40nxp.com%7C8c57174d86d447802a4908d936f6d729%7C686ea1d3bc2b4 c6fa92cd99c5c301635%7C0%7C0%7C637601256068970289%7CUnknown%7CTWFpbGZsb3d8eyJ WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata =BSU1cXFeV61T48OO68FHJVFxD4tnSHz%2FmndTUSWjLOE%3D&reserved=0> : TFM_SP_LOAD_LIST --> SP_LOAD_LIST * Patch 10385 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr ustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F10385&data=04%7C01 %7Candrey.butok%40nxp.com%7C8c57174d86d447802a4908d936f6d729%7C686ea1d3bc2b4 c6fa92cd99c5c301635%7C0%7C0%7C637601256068970289%7CUnknown%7CTWFpbGZsb3d8eyJ WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata =PYVkbSu05KgbqdUk%2FdCC7MAAg3KoNPKYXA4C1PrdnK0%3D&reserved=0> : TFM_SECURE_* --> SECURE_* Please help to put comments and inform us if your platforms couple tightly with the symbols defined in LD. Thanks, Xinyu

4 years, 4 months

2
1
0 0

Remove Customized Region Name Prefix in Linker Scripts

by Xinyu Zhang

Hi, The existing linker definitions abuse prefixes such as ER_ and TFM_. Some names do not have a clear scope, which reduces the readability. Here are some patches to address the problem: * Patch 10383<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10383>: TFM_UNPRIV_CODE --> UNPRIV_CODE * Patch 10384<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10384>: TFM_SP_LOAD_LIST --> SP_LOAD_LIST * Patch 10385<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10385>: TFM_SECURE_* --> SECURE_* Please help to put comments and inform us if your platforms couple tightly with the symbols defined in LD. Thanks, Xinyu

4 years, 4 months

1
0
0 0

Re: [TF-M] Technical Forum call - June 24

by Anton Komlev

HI, Having no declared topics for the forum, let's discuss the PSA Audit and TF-M logs features and scope to avoid possible confusion. Thanks and best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, June 16, 2021 4:07 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - June 24 Hi, The next Technical Forum is planned on Thursday, June 24 7:00-8:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 4 months

1
0
0 0

Re: [TF-M] Deprecate 'partitions/audit_logging' and its related tests

by Reed Hinkel

Hello Team: Audit Logging is a requirement for a number of e2e security schemes including Microsoft Azure. The implementation may need a bit of use case specific or customer steering to get back on track to demonstrating it will fit the bill for e2e usage. I would think carefully about the strategy here because I fully expect that the moment it is deprecated a business need for it to exist will be raised. Please carefully consider how to add support back in quickly if it is deprecated now, though I would personally like to see it retained. All the best! Reed From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Reply-To: Andrej Butok <andrey.butok(a)nxp.com> Date: Wednesday, June 16, 2021 at 5:56 AM To: Ken Liu <Ken.Liu(a)arm.com> Cc: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Deprecate 'partitions/audit_logging' and its related tests Hi Ken > Or any doubts about depreciating it? It is not used because its implementation is not finished, the current implementation is only for PSA L1 and not supported by IPC. This is not enough for certification. The Log service is optimally required by the PSA Certification. If you going to deprecate it, first delete the requirement from the PSA L2&L3 Certification profiles. Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Wednesday, June 16, 2021 10:46 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Deprecate 'partitions/audit_logging' and its related tests Hi, The component name under this folder is ‘Audit logging’, and: * There is no explicit specification or requirements for it, and its functionality is as a simple log collector (and looks no one is using it). * It supported under the library model only. And it is meaningless to move to IPC because of this. * It costs extra maintenance effort in test cases and partition code. So a plan is to deprecate this folder and its related test cases; will create a new one when the specification or requirements are explicitly defined. Question here is: Anyone is using this service? Or any doubts about depreciating it? Will collect the response and broadcast it at 25th Jun. Thanks. /Ken

4 years, 4 months

2
1
0 0

Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed

by David Hu

Hi, This secure test service, as I mentioned in the previous email, is for test purpose only. I’d like to recommend to implement a dedicated secure service to co-work with TF-M Initial Attestation service, to fulfil the specific use cases. This test service can be an example. The factory NS app and the dedicated secure service may work in a special device lifecycle. It may require additional mechanism to protect it from accesses in improper lifecycle. It may not be reasonable to mix an API with special purpose with TF-M Initial Attestation service following PSA Attestation API. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Friday, June 18, 2021 3:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi, The API is not fully disappeared, it still supported by a secure test service which can be optionally enabled at build time: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10226/ https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/10228 I think in this way a factory version of TF-M still can be used to export the public key, create a certificate for it (factory NS app) and pass on securely to the verification party to register the database. Kevin: Would this solution still satisfy your use case in mind? My thoughts regarding having the API part of the TF-M secure runtime (original solution): - I expect its usage is limited. Only at the beginning of device lifetime. * Removal of the API can reduce code size. * I cannot see how the API can be abused. Its usage can be clarified in the documentation. BR, Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: 2021. június 18., péntek 7:18 To: Kevin Townsend (kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>) <kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi Kevin, In a simplified common attestation protocol, the attestation verifier/validation entity (VE) uses the attestation public key to verify the attestation token sent from the device. The attestation VE is unable to verify the token, if it is not provided with the public key in advance. The public key fetched in device runtime is untrustworthy. Please check the details in Initial Attestation section in PSA Platform Security Model spec. On the other hand, usually clients on device don’t need attestation public key during attestation protocol execution. It is unnecessary to let Initial Attestation service to export IAK public key to other clients. Putting a dedicated API in attestation service to export public key can confuse developers. Sorry I’m not familiar with other use cases in which the attestation public key might be required and fetched on device in runtime. Those, if exist, may not be the typical use cases of TF-M Initial Attestation service. I’d suggest to implement dedicated secure services, to fulfill your requirement and use cases, relying on TF-M Initial Attestation. It is more flexible and convenient than mixing the public key fetch with TF-M Initial Attestation service. Best regards, Hu Ziji From: Kevin Townsend <kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>> Sent: Thursday, June 17, 2021 11:23 PM To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi, On Thu, 17 Jun 2021 at 16:49, David Hu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi all, Please note that API tfm_initial_attest_get_public_key() has been removed from TF-M Initial Attestation service. tfm_initial_attest_get_public_key() was defined by TF-M to retrieve Initial Attestation Key (IAK) public key in runtime. It is not defined by PSA Attestation API spec. It was designed for test purpose only but was always enabled in Initial Attestation service. TF-M regression tests called tfm_initial_attest_get_public_key() in runtime to retrieve IAK public key to verify the Initial Attestation Token (IAK) generated by Initial Attestation service. However, such a test implementation doesn’t fully align with common attestation protocols, in which the public key is usually distributed to the verifier when the device is deployed or registered. This API can be misleading and it concerned developers that it may be abused in actual production. Can you detail the use case(s) where you feel deriving the public key inside TF-M or the NS firmware can be abused? Personally, I find it quite useful to be able to generate the IAK randomly and retrieve the public key, which can safely be provided to the NS application to be passed on the end users. Providing the IAK public-key during factory provisioning assumes a very specific workflow that I don't think every TF-M product is likely to adopt. There are many other instances where we don't scrupulously follow the PSA APIs, so I'm not sure why this example should be highlighted, and what seems like a useful feature to me removed. If you can help me better understand the security concerns here, though, I can of course be persuaded otherwise! Best regards, Kevin

4 years, 4 months

1
0
0 0

Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed

by Tamas Ban

Hi, The API is not fully disappeared, it still supported by a secure test service which can be optionally enabled at build time: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10226/ https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/10228 I think in this way a factory version of TF-M still can be used to export the public key, create a certificate for it (factory NS app) and pass on securely to the verification party to register the database. Kevin: Would this solution still satisfy your use case in mind? My thoughts regarding having the API part of the TF-M secure runtime (original solution): - I expect its usage is limited. Only at the beginning of device lifetime. * Removal of the API can reduce code size. * I cannot see how the API can be abused. Its usage can be clarified in the documentation. BR, Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: 2021. június 18., péntek 7:18 To: Kevin Townsend (kevin.townsend(a)linaro.org) <kevin.townsend(a)linaro.org>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi Kevin, In a simplified common attestation protocol, the attestation verifier/validation entity (VE) uses the attestation public key to verify the attestation token sent from the device. The attestation VE is unable to verify the token, if it is not provided with the public key in advance. The public key fetched in device runtime is untrustworthy. Please check the details in Initial Attestation section in PSA Platform Security Model spec. On the other hand, usually clients on device don’t need attestation public key during attestation protocol execution. It is unnecessary to let Initial Attestation service to export IAK public key to other clients. Putting a dedicated API in attestation service to export public key can confuse developers. Sorry I’m not familiar with other use cases in which the attestation public key might be required and fetched on device in runtime. Those, if exist, may not be the typical use cases of TF-M Initial Attestation service. I’d suggest to implement dedicated secure services, to fulfill your requirement and use cases, relying on TF-M Initial Attestation. It is more flexible and convenient than mixing the public key fetch with TF-M Initial Attestation service. Best regards, Hu Ziji From: Kevin Townsend <kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>> Sent: Thursday, June 17, 2021 11:23 PM To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi, On Thu, 17 Jun 2021 at 16:49, David Hu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi all, Please note that API tfm_initial_attest_get_public_key() has been removed from TF-M Initial Attestation service. tfm_initial_attest_get_public_key() was defined by TF-M to retrieve Initial Attestation Key (IAK) public key in runtime. It is not defined by PSA Attestation API spec. It was designed for test purpose only but was always enabled in Initial Attestation service. TF-M regression tests called tfm_initial_attest_get_public_key() in runtime to retrieve IAK public key to verify the Initial Attestation Token (IAK) generated by Initial Attestation service. However, such a test implementation doesn’t fully align with common attestation protocols, in which the public key is usually distributed to the verifier when the device is deployed or registered. This API can be misleading and it concerned developers that it may be abused in actual production. Can you detail the use case(s) where you feel deriving the public key inside TF-M or the NS firmware can be abused? Personally, I find it quite useful to be able to generate the IAK randomly and retrieve the public key, which can safely be provided to the NS application to be passed on the end users. Providing the IAK public-key during factory provisioning assumes a very specific workflow that I don't think every TF-M product is likely to adopt. There are many other instances where we don't scrupulously follow the PSA APIs, so I'm not sure why this example should be highlighted, and what seems like a useful feature to me removed. If you can help me better understand the security concerns here, though, I can of course be persuaded otherwise! Best regards, Kevin

4 years, 4 months

1
0
0 0

Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed

by Kevin Townsend

Hi, On Thu, 17 Jun 2021 at 16:49, David Hu via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi all, > > > > Please note that API tfm_initial_attest_get_public_key() has been removed > from TF-M Initial Attestation service. > > > > tfm_initial_attest_get_public_key() was defined by TF-M to retrieve > Initial Attestation Key (IAK) public key in runtime. > > It is not defined by PSA Attestation API spec. It was designed for test > purpose only but was always enabled in Initial Attestation service. > > > > TF-M regression tests called tfm_initial_attest_get_public_key() in > runtime to retrieve IAK public key to verify the Initial Attestation Token > (IAK) generated by Initial Attestation service. > > However, such a test implementation doesn’t fully align with common > attestation protocols, in which the public key is usually distributed to > the verifier when the device is deployed or registered. > > This API can be misleading and it concerned developers that it may be > abused in actual production. > > Can you detail the use case(s) where you feel deriving the public key inside TF-M or the NS firmware can be abused? Personally, I find it quite useful to be able to generate the IAK randomly and retrieve the public key, which can safely be provided to the NS application to be passed on the end users. Providing the IAK public-key during factory provisioning assumes a very specific workflow that I don't think every TF-M product is likely to adopt. There are many other instances where we don't scrupulously follow the PSA APIs, so I'm not sure why this example should be highlighted, and what seems like a useful feature to me removed. If you can help me better understand the security concerns here, though, I can of course be persuaded otherwise! Best regards, Kevin

4 years, 4 months

2
1
0 0

Re: [TF-M] Building for Musca B1 with proxy service

by Chris.Brand＠infineon.com

Thanks for the quick response! That build now works for me. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, June 17, 2021 7:55 AM To: Mark Horvath <Mark.Horvath(a)arm.com>; Brand Chris (CSCA CSS ICW SW PSW 1) <Chris.Brand(a)infineon.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Building for Musca B1 with proxy service Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. The fix is merged. Thanks to Chris for reporting this issue. Also thanks to Mark for such a quick fix. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M Sent: Thursday, June 17, 2021 2:59 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> Subject: Re: [TF-M] Building for Musca B1 with proxy service Hi Chris, The build failure is a regression caused by moving the arm platforms under arm directory. Here is the patch to fix it: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10333 No need to pass artifacts from SE build to SSE-200 build, and the warning about the redefinition is not nice, but that does not cause any issue. Best regards, Mark ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Chris.Brand--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, June 16, 2021 11:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Building for Musca B1 with proxy service Hi, I'm trying to build for the Musca B1 with the proxy service. I understand that I have to two separate builds, one for the secure_enclave and one for the SSE-200. The secure enclave build works fine, but I'm getting errors for the SSE-200 build and my various attempts to get around them have all failed. I'm (also) wondering if there are artifacts form the secure_enclave build that need to feed into the SSE-200 build somehow, and if so how that works. Here's my command line and resulting errors: cmake -S . -B build_musca_sse200_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/sse_200 -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/bl0/bl0_main.c:17:0: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/gcc/startup_cmsdk_musca_bl2.S:20:10: fatal error: tfm_plat_config.h: No such file or directory #include "tfm_plat_config.h" ^~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/platform_description.h:23:0, from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/system_core_init.c:23: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/device_definition.c:29:10: fatal error: tfm_plat_defs.h: No such file or directory #include "tfm_plat_defs.h" ^~~~~~~~~~~~~~~~~ compilation terminated. [...] <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition [...] platform/target/bl0/CMakeFiles/bl0.dir/build.make:86: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... platform/target/bl0/CMakeFiles/bl0.dir/build.make:138: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:125: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:81: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o] Error 1 CMakeFiles/Makefile2:2539: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/all' failed gmake[1]: *** [platform/target/bl0/CMakeFiles/bl0.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs.... This is from a clean checkout of 54d47fbd5269 (current HEAD). I see that my tree does contain platform/ext/cmsis/core_cm33.h, platform/include/tfm_plat_config.h and platform/include/tfm_plat_defs.h so I guess it's the include paths that are messed up somehow...? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

4 years, 4 months

1
0
0 0

Re: [TF-M] Building for Musca B1 with proxy service

by David Hu

The fix is merged. Thanks to Chris for reporting this issue. Also thanks to Mark for such a quick fix. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: Thursday, June 17, 2021 2:59 PM To: tf-m(a)lists.trustedfirmware.org; Chris.Brand(a)infineon.com Subject: Re: [TF-M] Building for Musca B1 with proxy service Hi Chris, The build failure is a regression caused by moving the arm platforms under arm directory. Here is the patch to fix it: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10333 No need to pass artifacts from SE build to SSE-200 build, and the warning about the redefinition is not nice, but that does not cause any issue. Best regards, Mark ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Chris.Brand--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, June 16, 2021 11:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Building for Musca B1 with proxy service Hi, I'm trying to build for the Musca B1 with the proxy service. I understand that I have to two separate builds, one for the secure_enclave and one for the SSE-200. The secure enclave build works fine, but I'm getting errors for the SSE-200 build and my various attempts to get around them have all failed. I'm (also) wondering if there are artifacts form the secure_enclave build that need to feed into the SSE-200 build somehow, and if so how that works. Here's my command line and resulting errors: cmake -S . -B build_musca_sse200_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/sse_200 -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/bl0/bl0_main.c:17:0: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/gcc/startup_cmsdk_musca_bl2.S:20:10: fatal error: tfm_plat_config.h: No such file or directory #include "tfm_plat_config.h" ^~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/platform_description.h:23:0, from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/system_core_init.c:23: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/device_definition.c:29:10: fatal error: tfm_plat_defs.h: No such file or directory #include "tfm_plat_defs.h" ^~~~~~~~~~~~~~~~~ compilation terminated. [...] <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition [...] platform/target/bl0/CMakeFiles/bl0.dir/build.make:86: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... platform/target/bl0/CMakeFiles/bl0.dir/build.make:138: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:125: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:81: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o] Error 1 CMakeFiles/Makefile2:2539: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/all' failed gmake[1]: *** [platform/target/bl0/CMakeFiles/bl0.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs.... This is from a clean checkout of 54d47fbd5269 (current HEAD). I see that my tree does contain platform/ext/cmsis/core_cm33.h, platform/include/tfm_plat_config.h and platform/include/tfm_plat_defs.h so I guess it's the include paths that are messed up somehow...? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

4 years, 4 months

1
0
0 0

TF-M API tfm_initial_attest_get_public_key() has been removed

by David Hu

Hi all, Please note that API tfm_initial_attest_get_public_key() has been removed from TF-M Initial Attestation service. tfm_initial_attest_get_public_key() was defined by TF-M to retrieve Initial Attestation Key (IAK) public key in runtime. It is not defined by PSA Attestation API spec. It was designed for test purpose only but was always enabled in Initial Attestation service. TF-M regression tests called tfm_initial_attest_get_public_key() in runtime to retrieve IAK public key to verify the Initial Attestation Token (IAK) generated by Initial Attestation service. However, such a test implementation doesn't fully align with common attestation protocols, in which the public key is usually distributed to the verifier when the device is deployed or registered. This API can be misleading and it concerned developers that it may be abused in actual production. Therefore this API is removed now. A hard-coded dummy public key file is exported instead, to provide the pre-defined public key data to TF-M regression tests. This dummy public key is hard-coded here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…>. The removal of this API doesn't impact TF-M Initial Attestation service functionalities. TF-M Initial Attestation service still works as PSA attestation API spec requests. The changes to TF-M regression tests are either transparent to platform port or tests. However, there are two exceptions: - Currently, some develop boards with OTP enabled are provisioned with random IAK pair. The public key is unknown to the attestation verifier. Therefore a dedicated attestation test partition<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/test_services…> is added to workaround this issue. It adds back API tfm_initial_attest_get_public_key() to retrieve IAK public key in runtime. Boards with similar limitations can select flag ATTEST_TEST_GET_PUBLIC_KEY to enable this workaround during TF-M regression tests. This test partition is only available for TF-M regression tests. It is recommended to enable this workaround *only when it is necessary*. - When developers integrate TF-M with 3rd party test tool, developers can pick the dummy public key file and include it into IAK verification tests as public key input. Sorry for any inconvenience or trouble if this removal impacts your ongoing task. Please let me know if you have further questions about the removal of API tfm_initial_attest_get_public_key(). Best regards, Hu Ziji

4 years, 4 months

1
0
0 0

Re: [TF-M] Building for Musca B1 with proxy service

by Mark Horvath

Hi Chris, The build failure is a regression caused by moving the arm platforms under arm directory. Here is the patch to fix it: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10333 No need to pass artifacts from SE build to SSE-200 build, and the warning about the redefinition is not nice, but that does not cause any issue. Best regards, Mark ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Chris.Brand--- via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, June 16, 2021 11:34 PM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Building for Musca B1 with proxy service Hi, I’m trying to build for the Musca B1 with the proxy service. I understand that I have to two separate builds, one for the secure_enclave and one for the SSE-200. The secure enclave build works fine, but I’m getting errors for the SSE-200 build and my various attempts to get around them have all failed. I’m (also) wondering if there are artifacts form the secure_enclave build that need to feed into the SSE-200 build somehow, and if so how that works. Here's my command line and resulting errors: cmake -S . -B build_musca_sse200_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/sse_200 -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/bl0/bl0_main.c:17:0: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/gcc/startup_cmsdk_musca_bl2.S:20:10: fatal error: tfm_plat_config.h: No such file or directory #include "tfm_plat_config.h" ^~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/platform_description.h:23:0, from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/system_core_init.c:23: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/device_definition.c:29:10: fatal error: tfm_plat_defs.h: No such file or directory #include "tfm_plat_defs.h" ^~~~~~~~~~~~~~~~~ compilation terminated. […] <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition […] platform/target/bl0/CMakeFiles/bl0.dir/build.make:86: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... platform/target/bl0/CMakeFiles/bl0.dir/build.make:138: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:125: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:81: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o] Error 1 CMakeFiles/Makefile2:2539: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/all' failed gmake[1]: *** [platform/target/bl0/CMakeFiles/bl0.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs.... This is from a clean checkout of 54d47fbd5269 (current HEAD). I see that my tree does contain platform/ext/cmsis/core_cm33.h, platform/include/tfm_plat_config.h and platform/include/tfm_plat_defs.h so I guess it’s the include paths that are messed up somehow…? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

4 years, 4 months

1
0
0 0

Documentation URLs

by Anton Komlev

Hi, You might noticed that recently documentation became available under the static links (no randomized part in URL anymore). Now it possible to bookmark or share the TF-M docs using a human friendly short URLs like: https://tf-m-user-guide.trustedfirmware.org/docs/introduction/readme.html Please try and enjoy, Anton

4 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M