- TF-M - lists.trustedfirmware.org

by Ken Liu

Hi, There are some out of sync contents in the wiki page (mainly the design chapter), which needs to be cleaned a bit. https://developer.trustedfirmware.org/w/tf_m/ As the first step, the following article would be removed (Would move to a recyclable place at first): Cooperative Scheduling Rules - content out of date. Non-Secure Interrupt Handling - covered in the design document. Secure Partition Interrupt Handling - covered in the interrupt handling document. Service IPC compatibility - Attestation - low priority, no need to be a standalone item. Service IPC compatibility - SST - same as above. Trusted Firmware-m Isolation Level 2 - covered by document 'FF-M isolation'. Uniform Secure Service Signature - out of date, as most of related files are changed. Any comments please feel free to ping me. Would do this on Thursday (27th May) this week. Thanks. /Ken

4 years, 7 months

1
0
0 0

A question on tfm its filesystem

by Edward Yang

Hi, I'd like to ask a question to see if the filesystem part of tf-m its partition can be moved to lib/sprt folder,to make this filesystem a shared library for PRoT part of tfm. Therefore,besides its partition, other extra secure partitions can also make use of this filesystem. 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, 7 months

1
0
0 0

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

by Gyorgy Szing

Hi, Just a guess, but the "UNINIT" attribute described here [1] might be the one you are looking for. [1] https://developer.arm.com/documentation/100070/0612/scatter-file-syntax/exe… /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: 21 May 2021 03:22 To: Suresh.Marisetty(a)infineon.com; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] A question on Arm linker - GCC NOLOAD equivalent 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<mailto:tf-m-bounces@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<mailto:tf-m@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, 7 months

1
0
0 0

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

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M