- TF-M - lists.trustedfirmware.org

Re: [TF-M] A question on Arm linker - GCC NOLOAD equivalent

by David Hu

Hi Suresh, Could you please forward the question to Arm complier forum (https://community.arm.com/developer/tools-software/tools/f/arm-compilers-fo… I believe they can provide a more comprehensive answer. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: Friday, May 21, 2021 12:13 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] A question on Arm linker - GCC NOLOAD equivalent Wondering if anybody can answer this (may not be the right forum): >>I need the equivalent of the gcc NOLOAD attribute with armlink linker thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 5 months

1
0
0 0

A question on Arm linker - GCC NOLOAD equivalent

by Suresh.Marisetty＠infineon.com

Wondering if anybody can answer this (may not be the right forum): >>I need the equivalent of the gcc NOLOAD attribute with armlink linker thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 5 months

1
0
0 0

Tentative future TF-M release dates

by Shebu Varghese Kuriakose

Hi All, As many might know, TF-M is now making release tags around every 4 months as defined here<https://ci-builds.trustedfirmware.org/static-files/TZFdL484qZZgYcbWIGLS09zb…>. In order to help contributors and users of Trusted Firmware-M releases, the code freeze and release dates of the next 2 releases are published here<https://ci-builds.trustedfirmware.org/static-files/TZFdL484qZZgYcbWIGLS09zb…> (TF-M -> Docs -> Future release plans) Note that these dates are tentative and can shift if issues are identified leading upto the release. Regards, Shebu

4 years, 5 months

1
0
0 0

Technical Forum call - May 27

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, May 27 , 07:00-08: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, 5 months

1
0
0 0

CMSIS_5 pack cloning issue in old TF-M version

by Anton Komlev

Hi, Some of you using TF-M v1.0 or earlier may have experienced build failures recently because of the CMSIS_5 repo git-lfs quota. To avoid this issue, it is recommended to either update to the latest TF-M version or to manually download the CMSIS_5 pack without using git-lfs. TF-M only uses a small part of the CMSIS_5 pack for testing purposes. To avoid cloning the entire CMSIS_5 pack, TF-M has been using a forked copy of the required RTX libraries in the tf-m-tests repo since v1.1 so updating to any TF-M version including and after v1.1 is fine. Hope that helps, Anton K.

4 years, 5 months

1
0
0 0

Re: [TF-M] Factory provisioning with tf-m

by Tamas Ban

Hi Poppy, There is no reference implementation for the case when only attest service can access to IAK, which is stored in on-chip flash. Attest code is part of PRoT code, they have the same privileged level. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 2021. május 18., kedd 6:07 To: David Wang <David.Wang(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Factory provisioning with tf-m Hi Raef and David, Thanks for the detailed explanation. As I understand it,in the scenario without CC312 ,these keys(HUK,IAK,RoTPK) can be stored in secure-privileged area(using SAU and MPU) of embedded flash during factory provisioning,so these keys cannot be accessed by ARoT and non-secure code. But how to make IAK accessible only to the Initial Attestation Service？Is there any reference implementation? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Http: //www.mxic.com.cn David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>> 2021/05/17 20:54 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>>, Edward Yang <EdwardYang(a)mxic.com.cn<mailto:EdwardYang@mxic.com.cn>> cc nd <nd(a)arm.com<mailto:nd@arm.com>> Subject Re: [TF-M] Factory provisioning with tf-m Hi Poppy, One more thing about IAK, it's defined as one of the immutable PSA parameters in PSA security model document. And "To prevent cloning or spoofing, the IAK must be secret and accessible only to the Initial Attestation Service." In that case, for the product, you may need to consider how to ensure confidentiality/integrity and it's immutable based on the embedded flash solution. Regards, David Wang ARM Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 17 May 2021 16:50 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>>; Edward Yang <EdwardYang(a)mxic.com.cn<mailto:EdwardYang@mxic.com.cn>> Subject: Re: [TF-M] Factory provisioning with tf-m Hi Poppy. The current code we use for provisioning the CC312 OTP on the Musca reference platforms is under platform/ext/accelerator/cc312/cc312_provisioning.c, and the code for using keys from OTP is at platform/ext/target/musca_b1/sse_200/crypto_keys.c Note that because the Musca S1 has volatile OTP memory (I think it's a design choice that makes sense on a dev-board) a workaround is used, for the reference implementation it's best to look at the Musca B1. The basic flow is: * Build TF-M with -DCRYPTO_HW_ACCELERATOR_OTP_STATE=PROVISIONING, which will cause an ifdef in the bootloader to jump to the provisioning code instead of TF-M * TF-M then generates a 256 bit AES HUK and an ECC_P256 private key using the code in cc312_provisioning.c, and program these key into the OTP memory of the CC312 * Programming these keys into OTP causes the lifecycle state to be changed, so a reboot is needed between programming the keys to allow the new LCS to be used * The board is now provisioned - building TF-M with * -DCRYPTO_HW_ACCELERATOR_OTP_STATE=ON will cause TF-M to use the HUK, IAK and ROTPK from OTP, and will derive the SST/PS keys from the HUK on boot The general idea is that a platform can provide it's own implementation of the platform/ext/common/template/crypto_keys.c file, which could then load the keys from wherever they've been provisioned. I'd say it's reasonable to program keys into any NV storage region that is internal to the chip itself (and hence safe from tampering), which would include embedded flash. You'd then just need to load that data from flash in crypto_keys.c. Note that it would also be necessary to prevent secure partitions / non-secure code from directly accessing the flash where the keys are stored, probably by using an mpc/ppc to make it only accessible by secure-privileged code. Let me know if you have any other questions about the current CC312 provisioning flow. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 14 May 2021 10:04 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Factory provisioning with tf-m Hi, I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service? In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode). I think this is not allowed in production mode.Is there any recommended implementation of this API? What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？ tfm_plat_get_symmetric_iak( ) { TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size); } Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Http: //www.mxic.com.cn 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. ===================================================================== -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 5 months

1
0
0 0

Re: [TF-M] Factory provisioning with tf-m

by David Wang

Hi Poppy, One more thing about IAK, it's defined as one of the immutable PSA parameters in PSA security model document. And "To prevent cloning or spoofing, the IAK must be secret and accessible only to the Initial Attestation Service." In that case, for the product, you may need to consider how to ensure confidentiality/integrity and it's immutable based on the embedded flash solution. Regards, David Wang ARM Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 17 May 2021 16:50 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>; Edward Yang <EdwardYang(a)mxic.com.cn> Subject: Re: [TF-M] Factory provisioning with tf-m Hi Poppy. The current code we use for provisioning the CC312 OTP on the Musca reference platforms is under platform/ext/accelerator/cc312/cc312_provisioning.c, and the code for using keys from OTP is at platform/ext/target/musca_b1/sse_200/crypto_keys.c Note that because the Musca S1 has volatile OTP memory (I think it's a design choice that makes sense on a dev-board) a workaround is used, for the reference implementation it's best to look at the Musca B1. The basic flow is: * Build TF-M with -DCRYPTO_HW_ACCELERATOR_OTP_STATE=PROVISIONING, which will cause an ifdef in the bootloader to jump to the provisioning code instead of TF-M * TF-M then generates a 256 bit AES HUK and an ECC_P256 private key using the code in cc312_provisioning.c, and program these key into the OTP memory of the CC312 * Programming these keys into OTP causes the lifecycle state to be changed, so a reboot is needed between programming the keys to allow the new LCS to be used * The board is now provisioned - building TF-M with * -DCRYPTO_HW_ACCELERATOR_OTP_STATE=ON will cause TF-M to use the HUK, IAK and ROTPK from OTP, and will derive the SST/PS keys from the HUK on boot The general idea is that a platform can provide it's own implementation of the platform/ext/common/template/crypto_keys.c file, which could then load the keys from wherever they've been provisioned. I'd say it's reasonable to program keys into any NV storage region that is internal to the chip itself (and hence safe from tampering), which would include embedded flash. You'd then just need to load that data from flash in crypto_keys.c. Note that it would also be necessary to prevent secure partitions / non-secure code from directly accessing the flash where the keys are stored, probably by using an mpc/ppc to make it only accessible by secure-privileged code. Let me know if you have any other questions about the current CC312 provisioning flow. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 14 May 2021 10:04 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Factory provisioning with tf-m Hi, I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service? In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode). I think this is not allowed in production mode.Is there any recommended implementation of this API? What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？ tfm_plat_get_symmetric_iak( ) { TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size); } Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Http: //www.mxic.com.cn 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. ===================================================================== -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 5 months

2
1
0 0

MbedTLS version updated to 2.26.0

by Maulik Patel

Hello All, TF-M has been updated to work with MbedTLS version 2.26.0. Best Regards Maulik Patel

4 years, 5 months

1
0
0 0

Re: [TF-M] Factory provisioning with tf-m

by Raef Coles

Hi Poppy. The current code we use for provisioning the CC312 OTP on the Musca reference platforms is under platform/ext/accelerator/cc312/cc312_provisioning.c, and the code for using keys from OTP is at platform/ext/target/musca_b1/sse_200/crypto_keys.c Note that because the Musca S1 has volatile OTP memory (I think it's a design choice that makes sense on a dev-board) a workaround is used, for the reference implementation it's best to look at the Musca B1. The basic flow is: * Build TF-M with -DCRYPTO_HW_ACCELERATOR_OTP_STATE=PROVISIONING, which will cause an ifdef in the bootloader to jump to the provisioning code instead of TF-M * TF-M then generates a 256 bit AES HUK and an ECC_P256 private key using the code in cc312_provisioning.c, and program these key into the OTP memory of the CC312 * Programming these keys into OTP causes the lifecycle state to be changed, so a reboot is needed between programming the keys to allow the new LCS to be used * The board is now provisioned - building TF-M with * -DCRYPTO_HW_ACCELERATOR_OTP_STATE=ON will cause TF-M to use the HUK, IAK and ROTPK from OTP, and will derive the SST/PS keys from the HUK on boot The general idea is that a platform can provide it's own implementation of the platform/ext/common/template/crypto_keys.c file, which could then load the keys from wherever they've been provisioned. I'd say it's reasonable to program keys into any NV storage region that is internal to the chip itself (and hence safe from tampering), which would include embedded flash. You'd then just need to load that data from flash in crypto_keys.c. Note that it would also be necessary to prevent secure partitions / non-secure code from directly accessing the flash where the keys are stored, probably by using an mpc/ppc to make it only accessible by secure-privileged code. Let me know if you have any other questions about the current CC312 provisioning flow. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 14 May 2021 10:04 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Factory provisioning with tf-m Hi, I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service? In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode). I think this is not allowed in production mode.Is there any recommended implementation of this API? What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？ tfm_plat_get_symmetric_iak( ) { TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size); } Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Http: //www.mxic.com.cn 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, 5 months

1
0
0 0

Re: [TF-M] Factory provisioning with tf-m

by Edward Yang

Hi Shebu, Thanks for your reply.I would like to know is there any reference usage example of tf-m available now? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Http: //www.mxic.com.cn ----- Forwarded by Edward Yang/CHINA/MXIC on 2021/05/17 11:56 ----- Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com> 2021/05/15 01:19 To Edward Yang <EdwardYang(a)mxic.com.cn>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject RE: [TF-M] Factory provisioning with tf-m Hi Poppy, In the roadmap, provisioning service is noted incase there is any standard provisioning mechanism that PSA defines in future. There is no plans around provisioning at this point. It is upto the platform to generate the keys and provision it securely on the device which TF-M can make use of. On Arm reference platforms, MuscaB1 and MuscaS1, the HUK, IAK are generated in Cryptocell-312. HUK, IAK private keys and ROTPK are provisioned in the OTP of CC-312. The hardcoding of keys in TF-M is just for development purposes and not to be used in production environment. Provisioning the attestation key in the secure region of the embedded flash might be acceptable. Experts in the list can comment. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Friday, May 14, 2021 10:04 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Factory provisioning with tf-m Hi, I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service? In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode). I think this is not allowed in production mode.Is there any recommended implementation of this API? What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？ tfm_plat_get_symmetric_iak( ) { TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size); } Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Http: //www.mxic.com.cn 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. ===================================================================== ============================================================================ 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 it attachments 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, 5 months

1
0
0 0

Re: [TF-M] Factory provisioning with tf-m

by Shebu Varghese Kuriakose

Hi Poppy, In the roadmap, provisioning service is noted incase there is any standard provisioning mechanism that PSA defines in future. There is no plans around provisioning at this point. It is upto the platform to generate the keys and provision it securely on the device which TF-M can make use of. On Arm reference platforms, MuscaB1 and MuscaS1, the HUK, IAK are generated in Cryptocell-312. HUK, IAK private keys and ROTPK are provisioned in the OTP of CC-312. The hardcoding of keys in TF-M is just for development purposes and not to be used in production environment. Provisioning the attestation key in the secure region of the embedded flash might be acceptable. Experts in the list can comment. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Friday, May 14, 2021 10:04 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Factory provisioning with tf-m Hi, I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service? In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode). I think this is not allowed in production mode.Is there any recommended implementation of this API? What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？ tfm_plat_get_symmetric_iak( ) { TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size); } Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Http: //www.mxic.com.cn 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, 5 months

1
0
0 0

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

by David Hu

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> On Behalf Of Suresh Marisetty via TF-M Sent: Thursday, May 13, 2021 6:04 AM To: Tamas Ban <Tamas.Ban(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)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, 5 months

2
1
0 0

Factory provisioning with tf-m

by Edward Yang

Hi, I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service? In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode). I think this is not allowed in production mode.Is there any recommended implementation of this API? What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？ tfm_plat_get_symmetric_iak( ) { TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size); } Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Http: //www.mxic.com.cn ============================================================================ 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, 5 months

1
0
0 0

Re: [TF-M] Technical Forum call - May 13

by Anton Komlev

Hi, The agenda for the forum today: 1. How to use docker to build TFM on Windows and Linux by Hugo L'hostis 2. Linker script/scatter file templating (preliminary and tentative) 3. AOB Regards, Anton From: docker to build TFM on windows and Linux (It should take 10 to 15 minutes). <Hugo.Lhostis(a)arm.com> Sent: Wednesday, May 12, 2021 10:36 AM To: Anton Komlev <Anton.Komlev(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: Technical Forum call - May 13 Hi Anton, I would like to speak about using docker to build TFM on windows and Linux (It should take 10 to 15 minutes). Best regards, Hugo From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: 06 May 2021 19:20 To: 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] Technical Forum call - May 13 Hi, The next Technical Forum is planned on Thursday, May 13, 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, 5 months

1
0
0 0

Firmware update API - MCUboot update

by Suresh.Marisetty＠infineon.com

Hi, I would like to see if there is any guidance/documentation on how to coordinate between the firmware update services API with that of MCUboot. Does the use of this API make the MCUboot update services redundant? thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 5 months

1
0
0 0

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

by Tamas Ban

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> 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 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, 5 months

2
1
0 0

Security vulnerability notice - abort() function may not take effect in TF-M Crypto multi-part operations

by David Wang

Hi Everyone, This email is a notification of a new security vulnerability reported to TF-M. It's about the Crypto service in TF-M - abort() function may not take effect in TF-M Crypto multi-part MAC/hashing/cipher operations. Please check the details in the security advisory attached. (.rst version is coming soon) The fix has been merged on the latest master branch - Crypto: Remove unnecessary multi-part operation clean-up (I9cd0fa38) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9932> We're planning a hot fix release. Will share the plan with you when it's ready. Thanks. Regards, David Wang ARM Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142)

4 years, 5 months

1
0
0 0

[RFC] Overall Secure Partition Management (SPM) design document

by Ken Liu

Hi everyone, SPM came at the begging of the project, so the design document was spread into several small pieces as features. Now it is a chance to provide an overall document as we are going to have significant feature updates for FFM 1.1. Here is the draft of the design document: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9928 This document is trying to address the overall design for 1.1 much. It based on FFM 1.1 update alpha stage document. Several points: * I want to publish this document public earlier for a quick taste, even though some features are not introduced yet (such as MMIOVEC), so there defecation would be some missing items, and I would keep updating recently. * Meanwhile, I would collect feedbacks from you and update them into the design document, too. * Prototype would be performed to see the situation. * In this document I am trying to tell the conclusion directly instead of go over the conceptual items described in FF-M. If you can not find background either in this document or in the specification please tell me, I would try to add the missing part. Or if you think some text is quite redundant, tell me and I would remove the without hesitation. The 1.1 specification (alpha): https://developer.arm.com/documentation/aes0039/latest Please provide your feedback - both mailing list and patch are welcome (in the patch is more welcome, as there may be long discussions so patch comment is easier to be tracked). Thanks! /Ken

4 years, 5 months

1
0
0 0

Re: [TF-M] Technical Forum call - May 13

by Ken Liu

Hi Anton, I would like to discuss the linker script integration things, would summarized the situation and potential improvement plan. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, May 7, 2021 2:20 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - May 13 Hi, The next Technical Forum is planned on Thursday, May 13, 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, 5 months

1
0
0 0

Technical Forum call - May 13

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, May 13, 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, 6 months

1
0
0 0

Re: [TF-M] Timeframe on release/approval

by David Wang

Hi Jamie, The patch has been reviewed and merged. Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M Sent: Thursday, May 6, 2021 2:48 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Timeframe on release/approval Hi, Would it be possible to get some quick reviews on some fixes and a missing file for our board at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9882 please? Thanks, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Tamas Ban via TF-M Sent: 14 April 2021 08:35 To: 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] Timeframe on release/approval Hi, TF-M release cadence is 4 month. In theory 1.4 release is around July. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Mccrae via TF-M Sent: 2021. április 14., szerda 8:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Timeframe on release/approval Hi Minos/David/Shebu, Many thanks for the details. Is there a timeframe in mind for the next major release of TF-M i.e. version 1.4? Thanks, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: 13 April 2021 17:57 To: 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] Timeframe on release/approval Hi Jamie, My understanding is that Zephyr integrates release tags of TF-M. TF-M v1.2 was integrated and I assume v1.3 will be done sometime soon. Regards, Shebu 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: Tuesday, April 13, 2021 3:14 AM To: 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] Timeframe on release/approval Hi Jaime, Anton and I have reviewed your patch. Please check our comments on the patch. I believe other reviewers will provide their input as well soon. Although it is difficult to guarantee the timeframe in TF-M as in other open-source project, it will speed up the review process if reviewers’ comments can be addressed in time. 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Minos Galanakis via TF-M Sent: Tuesday, April 13, 2021 12:09 AM To: 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] Timeframe on release/approval Hi Jamie, Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process. To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure. Regards, Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Jamie Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 12 April 2021 09:40 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] Timeframe on release/approval Hi, I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file? Thanks, Jamie THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

4 years, 6 months

2
1
0 0

Re: [TF-M] Timeframe on release/approval

by Kevin Townsend

Hi Shebu, Just as a FYI TF-M 1.3 has already been integrated into Zephyr and will be part of the 2.6.0 release, scheduled for the end of the month. If TF-M 1.4 happens in July, that will likely be the version that Zephyr 2.7.0 will likely use, which will be an LTS release. Kevin On Tue, 13 Apr 2021 at 18:57, Shebu Varghese Kuriakose via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi Jamie, > > > > My understanding is that Zephyr integrates release tags of TF-M. TF-M v1.2 > was integrated and I assume v1.3 will be done sometime soon. > > > > Regards, > > Shebu > > > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> * On Behalf Of *David > Hu via TF-M > *Sent:* Tuesday, April 13, 2021 3:14 AM > *To:* tf-m(a)lists.trustedfirmware.org > *Cc:* nd <nd(a)arm.com> > *Subject:* Re: [TF-M] Timeframe on release/approval > > > > Hi Jaime, > > > > Anton and I have reviewed your patch. Please check our comments on the > patch. > > I believe other reviewers will provide their input as well soon. > > Although it is difficult to guarantee the timeframe in TF-M as in other > open-source project, it will speed up the review process if reviewers’ > comments can be addressed in time. 😊 > > > > Best regards, > > Hu Ziji > > > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Minos > Galanakis via TF-M > *Sent:* Tuesday, April 13, 2021 12:09 AM > *To:* tf-m(a)lists.trustedfirmware.org > *Cc:* nd <nd(a)arm.com> > *Subject:* Re: [TF-M] Timeframe on release/approval > > > > Hi Jamie, > > > > Thank you very much for your interest in supporting for TF-M in your > platform. Since you are contributing a new platform, I would recommend that > you read the Trusted Firmware maintenance process > <https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, > for further details on the process. > > > > To answer your questions about the timeframe, that really depends on > various factors, such as how busy the maintainers of this code are, weather > there is a release pending which would follow a code freeze, and how > complicated the changes are. I don't believe it is easy to estimate a > figure. > > > > Regards, > > Minos > > > ------------------------------ > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Jamie > Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org> > *Sent:* 12 April 2021 09:40 > *To:* tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> > *Subject:* [TF-M] Timeframe on release/approval > > > > Hi, > > I submitted a patch to add our board to the Trusted Firmware-M repository > under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 > and was wondering on timeframes for receiving comments or having the pull > request accepted? We want to have our board added to Zephyr RTOS and for > that, we need the board in TF-M and pulled into the Zephyr version of this > repository (I’m not sure if they can pull any version of the code or if > they only pull full release versions e.g. 1.3.0), are there any comments on > this and does anyone have any idea of a rough estimate the time required > from now to get the base files into the zephyr version of the repository so > we can submit our boards file? > > Thanks, > > Jamie > > THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY > BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY > FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED > RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY > NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE > PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED > WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

4 years, 6 months

1
0
0 0

Re: [TF-M] Timeframe on release/approval

by Jamie Mccrae

Hi, Would it be possible to get some quick reviews on some fixes and a missing file for our board at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9882 please? Thanks, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: 14 April 2021 08:35 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Timeframe on release/approval Hi, TF-M release cadence is 4 month. In theory 1.4 release is around July. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M Sent: 2021. április 14., szerda 8:10 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Timeframe on release/approval Hi Minos/David/Shebu, Many thanks for the details. Is there a timeframe in mind for the next major release of TF-M i.e. version 1.4? Thanks, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: 13 April 2021 17:57 To: 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] Timeframe on release/approval Hi Jamie, My understanding is that Zephyr integrates release tags of TF-M. TF-M v1.2 was integrated and I assume v1.3 will be done sometime soon. Regards, Shebu 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: Tuesday, April 13, 2021 3:14 AM To: 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] Timeframe on release/approval Hi Jaime, Anton and I have reviewed your patch. Please check our comments on the patch. I believe other reviewers will provide their input as well soon. Although it is difficult to guarantee the timeframe in TF-M as in other open-source project, it will speed up the review process if reviewers’ comments can be addressed in time. 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Minos Galanakis via TF-M Sent: Tuesday, April 13, 2021 12:09 AM To: 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] Timeframe on release/approval Hi Jamie, Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process. To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure. Regards, Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Jamie Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 12 April 2021 09:40 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] Timeframe on release/approval Hi, I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file? Thanks, Jamie THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

4 years, 6 months

1
0
0 0

Re: [TF-M] [FIH lib] : fih question on a specific fault injection

by Raef Coles

I think at the moment that wouldn't get caught by the flow control countermeasures. However, we did have an idea for an improvement (which didn't get implemented), that should resolve it. At the moment, calling a function with FIH_CALL increases the flow control counter by 1. The alternative we considered was to instead increase the counter by a value that was generated based on the function that was called. Exactly how to generate this number is tricky, since we can't really implement a proper hash function in the preprocessor. The compromise we came to was that we could increase it by sizeof(__func__), (the length of the function name). This is accessible to both the call and the ret, and should be reasonably easily implementable. This wouldn't solve your issue immediately, but one function could then be renamed to be of different length. Another alternative is that you could manually increment and check the flow-control counter, though having to do that manually isn't ideal. Do either of these options seem reasonable? Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Michel JAOUEN via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 30 April 2021 13:55 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] [FIH lib] : fih question on a specific fault injection Hello I start using FIH library and I doubt that it can solve following fault injection : Here are 2 tests function being placed by linker very closed from each other to make possible to jump from test_1 start address to test_2 start address with a fault injection. fih_int test_1(void) { fih_int fih_rc = FIH_FAILURE; fih_rc = fih_int_encode(TFM_PLAT_ERR_SUCCESS); FIH_RET(fih_rc); } fih_int test_2(void) { fih_int fih_rc = FIH_FAILURE; fih_rc = fih_int_encode(TFM_PLAT_ERR_SUCCESS); FIH_RET(fih_rc); } Is the following able to detect that code return from test_2 instead of test_1 after such fault ? FIH_CALL(test_1()); if (fih_not_eq(fih_rc, fih_int_encode(TFM_HAL_SUCCESS))) { tfm_core_panic(); } Best regards Michel

4 years, 6 months

2
1
0 0

[FIH lib] : fih question on a specific fault injection

by Michel JAOUEN

Hello I start using FIH library and I doubt that it can solve following fault injection : Here are 2 tests function being placed by linker very closed from each other to make possible to jump from test_1 start address to test_2 start address with a fault injection. fih_int test_1(void) { fih_int fih_rc = FIH_FAILURE; fih_rc = fih_int_encode(TFM_PLAT_ERR_SUCCESS); FIH_RET(fih_rc); } fih_int test_2(void) { fih_int fih_rc = FIH_FAILURE; fih_rc = fih_int_encode(TFM_PLAT_ERR_SUCCESS); FIH_RET(fih_rc); } Is the following able to detect that code return from test_2 instead of test_1 after such fault ? FIH_CALL(test_1()); if (fih_not_eq(fih_rc, fih_int_encode(TFM_HAL_SUCCESS))) { tfm_core_panic(); } Best regards Michel

4 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M