- TF-M - lists.trustedfirmware.org

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

Building for Musca B1 with proxy service

by Chris.Brand＠infineon.com

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

Technical Forum call - June 24

by Anton Komlev

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 Andrej Butok

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

1
0
0 0

Deprecate 'partitions/audit_logging' and its related tests

by Ken Liu

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

1
0
0 0

Updated invitation with note: TF-M Tech forum @ Every 4 weeks from 12am to 1am on Thursday (MST) (tf-m@lists.trustedfirmware.org)

by Don Harbin

This event has been changed with this note: "Extending end date" Title: TF-M Tech forum About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==…Topic: TF-M Tech forum - Asia Time Zone FriendlyTime: Nov 12, 2020 07:00 AM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 4, 2021, 5 occurrence(s)        Nov 12, 2020 07:00 AM        Dec 10, 2020 07:00 AM        Jan 7, 2021 07:00 AM        Feb 4, 2021 07:00 AM        Mar 4, 2021 07:00 AMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT09Meeting ID: 925 3579 4925Passcode: 414410One tap mobile+12532158782,,92535794925# US (Tacoma)+13462487799,,92535794925# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 925 3579 4925Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW When: Every 4 weeks from 12am to 1am on Thursday Mountain Standard Time - Phoenix (changed) Where: https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… Calendar: tf-m(a)lists.trustedfirmware.org Who: * Don Harbin - creator * tf-m(a)lists.trustedfirmware.org * anton.komlev(a)arm.com * leonardo.sandoval(a)linaro.org * abdelmalek.omar1(a)gmail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 4 months

1
0
0 0

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

by David Wang

Hi Anton, If it's open agenda, I would like to take this opportunity to get some inputs about the use scenarios and solutions for sharing flash controller (or even other HW resources) between S and NS. For example, the security/concurrency concerns/issues etc. Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, June 9, 2021 11:03 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Technical Forum call - June 10 Hi, We have an open agenda for the forum tomorrow. Let's use that time to review any ongoing items and discuss open questions. To start: 1. What kind of project measurements would be interesting for collection and ways for benchmarking. * Booting time * PSA service access time * ... anything else ? Regards and please bring your topic, Anton 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: Wednesday, June 2, 2021 11:26 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: [TF-M] Technical Forum call - June 10 Hi, The next Technical Forum is planned on Thursday, June 10, 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

2
1
0 0

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

by Anton Komlev

Hi, We have an open agenda for the forum tomorrow. Let's use that time to review any ongoing items and discuss open questions. To start: 1. What kind of project measurements would be interesting for collection and ways for benchmarking. * Booting time * PSA service access time * ... anything else ? Regards and please bring your topic, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, June 2, 2021 11:26 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - June 10 Hi, The next Technical Forum is planned on Thursday, June 10, 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

Arm platforms moved into arm folder

by Summer Qin

Hi, We have moved all arm platforms into arm folder which will make the platform folder more clear. One thing needs to pay attention to is that you need to change the TFM_PLATFORM when building arm platforms. For example: '-DTFM_PLATFORM=mps2/an521' --> '-DTFM_PLATFORM=arm/mps2/an521'. It does not influence partner platforms build commands, only for arm platforms. Best Regards, Summer

4 years, 4 months

1
0
0 0

Re: [TF-M] Questions about psa crypto persistent key

by Andrej Butok

Hi Poppy Wu > the macro TFM_HUK_KEY_ADDR below may be a pointer to the shared HUK data(stored in secure RAM) from secure boot? Yes, this is a pointer to a HUK, provisioned in a secure memory region. Best regards, Andrej Butok SW Tech Lead Edge Processing NXP Semiconductors From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Thursday, June 3, 2021 12:13 PM To: tf-m(a)lists.trustedfirmware.org; Sherry Zhang <Sherry.Zhang2(a)arm.com> Subject: Re: [TF-M] Questions about psa crypto persistent key Hi Sherry, Thanks a lot for your reply,it's a big help. So with current tf-m crypto service implementation,if I want to use psa_aead_encrypt() to do encryption with a persistent key which is provisioned before the reset,I need to use psa_open_key() as a temporary method. Besides,the implementation of key derivation from HUK on NXP platform,I suppose in actual development ,the macro TFM_HUK_KEY_ADDR below may be a pointer to the shared HUK data(stored in secure RAM) from secure boot? +#ifndef TFM_HUK_KEY_ADDR +static const uint8_t sample_tfm_key[] = + {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, \ + 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F}; + +#define TFM_HUK_KEY_ADDR sample_tfm_key +#endif status = psa_import_key(&attributes, (const uint8_t *)TFM_HUK_KEY_ADDR, TFM_HUK_KEY_LEN, &base_key); Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mxic.c om.cn%2F&data=04%7C01%7Candrey.butok%40nxp.com%7Ca93215d45b04467d08a008d9267 83c86%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637583120130280321%7CUnkn own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC I6Mn0%3D%7C1000&sdata=rkCPRgsZNK6j3xKoAJkJQDjPW8nA6RDW6JosI0EbSOY%3D&reserve d=0> http://www.mxic.com.cn Sherry Zhang via TF-M <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> > Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org <mailto:tf-m-bounces@lists.trustedfirmware.org> > 2021/06/03 14:23 Please respond to Sherry Zhang <Sherry.Zhang2(a)arm.com <mailto:Sherry.Zhang2@arm.com> > To Edward Yang <EdwardYang(a)mxic.com.cn <mailto:EdwardYang@mxic.com.cn> >, "tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.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] Questions about psa crypto persistent key Hi Poppy, The updated PSA crypto spec supports calling psa_aead_encrypt to do encryption with a persistent key which is provisioned before the reset. But currently, the TF-M crypto service has not been updated to the updated PSA crypto spec version in which the psa_open_key is removed. Currently, in TFM, the persistent key should be opened by calling psa_open_key before using this key to do crypto operations which follows the older version of spec. The tfm_crypto_check_handle_owner() API is used for the isolation between the clients. When aligning to the new PSA crypto spec, the isolation implementation should be updated accordingly. Regards, Sherry Zhang From: Edward Yang <EdwardYang(a)mxic.com.cn <mailto:EdwardYang@mxic.com.cn> > Sent: Thursday, June 3, 2021 11:03 AM To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> ; Sherry Zhang <Sherry.Zhang2(a)arm.com <mailto:Sherry.Zhang2@arm.com> > Subject: Re: [TF-M] Questions about psa crypto persistent key Hi Sherry, Import persistent key with a specified key_id is indeed supported in the updated crypto spec.. I mean,if a key created by derivation functions,and this key is imported as a persistent key with s specific key id such as KEY_ID_EXAMPLE,then this key is stored in internal Flash with its service. After the reset,this persistent key still exists,but this persisten key cannot be used to do encryption directly,for example,call psa_aead_encrypt(KEY_ID_EXAMPLE,alg,nonce,...),unless import this key with psa_import() once again. Call psa_aead_encrypt(SSKEY_ID,alg,nonce,...) without calling psa_import_key() in advance is not allowed,because in tfm_crypto_check_handle_owner()(why this API is needed?)it will check this key_id with handle_owner[] array. So I am wondering what's the intended use of persistent keys? After creation, this persistent keys can only be used to derive other encryption keys,rather than used to encrypt data with themselves? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mxic.c om.cn%2F&data=04%7C01%7Candrey.butok%40nxp.com%7Ca93215d45b04467d08a008d9267 83c86%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637583120130285299%7CUnkn own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC I6Mn0%3D%7C1000&sdata=zQkONnZCSzkuPTyBfrf9yGAxpYw4iT1J7GImry15nNs%3D&reserve d=0> http://www.mxic.com.cn Sherry Zhang via TF-M < <mailto:tf-m@lists.trustedfirmware.org> tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" < <mailto:tf-m-bounces@lists.trustedfirmware.org> tf-m-bounces(a)lists.trustedfirmware.org> 2021/06/02 17:37 Please respond to Sherry Zhang < <mailto:Sherry.Zhang2@arm.com> Sherry.Zhang2(a)arm.com> To " <mailto:tf-m@lists.trustedfirmware.org> tf-m(a)lists.trustedfirmware.org" < <mailto:tf-m@lists.trustedfirmware.org> tf-m(a)lists.trustedfirmware.org> cc nd < <mailto:nd@arm.com> nd(a)arm.com> Subject Re: [TF-M] Questions about psa crypto persistent key Hi Poppy, Some feedback from my understanding on the first question. 1. Import persistent key with a key_id is still supported in the updated PSA crypto spec. In the version of PSA crypto spec in which psa_open_key is supported, the persistent key can be opened after the reset with the key_id which is specified in the key attributes in key creation. This is not very friendly. The reason is that each time the user calls the psa_open_key, the crypto service loads the key material from slot to running area(ram or flash) thus a new associated resources is allocated. The application must eventually call psa_close_key to release the allocated associated resources. It can happen that multiple applications call psa_open_key multile times as they may do not know whether the key is opened by other applications. So it can happen that multiple copies of associated resources are allocated for the same key. This is not user friendly. In the updated PSA crypto spec, the key material management strategy is changed. The user does not need to call the psa_open_key to load the key from slot to ram/flash. See the section of "9.4 Key identifies" of the spec: ``` Key identifiers are output from a successful call to one of the key creation functions. For persistent keys, this is the same identifier as the one specified in the key attributes used to create the key. The key indenter remains valid until it is invalidated by passing it to psa_destroy_key(). A volatile key identifier must not be used after it has been invalidated. ``` So I think the user can use the key_id directly to call crypto operations, such as means encrypt, decrypt. Regards, Sherry Zhang From: TF-M < <mailto:tf-m-bounces@lists.trustedfirmware.org> tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, June 2, 2021 1:30 PM To: <mailto:tf-m@lists.trustedfirmware.org> tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mxic.c om.cn%2F&data=04%7C01%7Candrey.butok%40nxp.com%7Ca93215d45b04467d08a008d9267 83c86%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637583120130290277%7CUnkn own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC I6Mn0%3D%7C1000&sdata=Qq7wg%2BW9xen65%2BTArZ2w33nPvaB9iHjOOKNcwkyyXu0%3D&res erved=0> 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 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. =====================================================================-- TF-M mailing list <mailto:TF-M@lists.trustedfirmware.org> TF-M(a)lists.trustedfirmware.org <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru stedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=04%7C01%7Candrey.butok%40n xp.com%7Ca93215d45b04467d08a008d926783c86%7C686ea1d3bc2b4c6fa92cd99c5c301635 %7C0%7C0%7C637583120130295255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eGRG%2B6%2FzEx1FqR KyA2jtUfD6sSXEPYeC5Uo%2F8rtDjaQ%3D&reserved=0> https://lists.trustedfirmware.org/mailman/listinfo/tf-m-- TF-M mailing list TF-M(a)lists.trustedfirmware.org <mailto:TF-M@lists.trustedfirmware.org> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru stedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=04%7C01%7Candrey.butok%40n xp.com%7Ca93215d45b04467d08a008d926783c86%7C686ea1d3bc2b4c6fa92cd99c5c301635 %7C0%7C0%7C637583120130300233%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dLJ8SzvGNpE%2FKodd C%2FNFToPCiOiS2w3ir%2FlaiZ4q6ug%3D&reserved=0> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 5 months

1
0
0 0

Re: [TF-M] Questions about psa crypto persistent key

by Edward Yang

Hi Sherry, Thanks a lot for your reply,it's a big help. So with current tf-m crypto service implementation,if I want to use psa_aead_encrypt() to do encryption with a persistent key which is provisioned before the reset,I need to use psa_open_key() as a temporary method. Besides,the implementation of key derivation from HUK on NXP platform,I suppose in actual development ,the macro TFM_HUK_KEY_ADDR below may be a pointer to the shared HUK data(stored in secure RAM) from secure boot? +#ifndef TFM_HUK_KEY_ADDR +static const uint8_t sample_tfm_key[] = + {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, \ + 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F}; + +#define TFM_HUK_KEY_ADDR sample_tfm_key +#endif status = psa_import_key(&attributes, (const uint8_t *)TFM_HUK_KEY_ADDR, TFM_HUK_KEY_LEN, &base_key); Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn Sherry Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2021/06/03 14:23 Please respond to Sherry Zhang <Sherry.Zhang2(a)arm.com> 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] Questions about psa crypto persistent key Hi Poppy, The updated PSA crypto spec supports calling psa_aead_encrypt to do encryption with a persistent key which is provisioned before the reset. But currently, the TF-M crypto service has not been updated to the updated PSA crypto spec version in which the psa_open_key is removed. Currently, in TFM, the persistent key should be opened by calling psa_open_key before using this key to do crypto operations which follows the older version of spec. The tfm_crypto_check_handle_owner() API is used for the isolation between the clients. When aligning to the new PSA crypto spec, the isolation implementation should be updated accordingly. Regards, Sherry Zhang From: Edward Yang <EdwardYang(a)mxic.com.cn> Sent: Thursday, June 3, 2021 11:03 AM To: tf-m(a)lists.trustedfirmware.org; Sherry Zhang <Sherry.Zhang2(a)arm.com> Subject: Re: [TF-M] Questions about psa crypto persistent key Hi Sherry, Import persistent key with a specified key_id is indeed supported in the updated crypto spec.. I mean,if a key created by derivation functions,and this key is imported as a persistent key with s specific key id such as KEY_ID_EXAMPLE,then this key is stored in internal Flash with its service. After the reset,this persistent key still exists,but this persisten key cannot be used to do encryption directly,for example,call psa_aead_encrypt(KEY_ID_EXAMPLE,alg,nonce,...),unless import this key with psa_import() once again. Call psa_aead_encrypt(SSKEY_ID,alg,nonce,...) without calling psa_import_key() in advance is not allowed,because in tfm_crypto_check_handle_owner()(why this API is needed?)it will check this key_id with handle_owner[] array. So I am wondering what's the intended use of persistent keys? After creation, this persistent keys can only be used to derive other encryption keys,rather than used to encrypt data with themselves? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn Sherry Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2021/06/02 17:37 Please respond to Sherry Zhang <Sherry.Zhang2(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject Re: [TF-M] Questions about psa crypto persistent key Hi Poppy, Some feedback from my understanding on the first question. 1. Import persistent key with a key_id is still supported in the updated PSA crypto spec. In the version of PSA crypto spec in which psa_open_key is supported, the persistent key can be opened after the reset with the key_id which is specified in the key attributes in key creation. This is not very friendly. The reason is that each time the user calls the psa_open_key, the crypto service loads the key material from slot to running area(ram or flash) thus a new associated resources is allocated. The application must eventually call psa_close_key to release the allocated associated resources. It can happen that multiple applications call psa_open_key multile times as they may do not know whether the key is opened by other applications. So it can happen that multiple copies of associated resources are allocated for the same key. This is not user friendly. In the updated PSA crypto spec, the key material management strategy is changed. The user does not need to call the psa_open_key to load the key from slot to ram/flash. See the section of “9.4 Key identifies” of the spec: ``` Key identifiers are output from a successful call to one of the key creation functions. For persistent keys, this is the same identifier as the one specified in the key attributes used to create the key. The key indenter remains valid until it is invalidated by passing it to psa_destroy_key(). A volatile key identifier must not be used after it has been invalidated. ``` So I think the user can use the key_id directly to call crypto operations, such as means encrypt, decrypt. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, June 2, 2021 1:30 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? 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 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. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m-- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m ============================================================================ 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] Questions about psa crypto persistent key

by Sherry Zhang

Hi Poppy, Question 2 and 3: In the PSA crypto spec, the Key derivation function section describes the steps to perform a key derivation. Also I think you can take the implementation of the key generation based on HUK on NXP platform as a reference at https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…. TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h is a temp work before persistent key APIs support in general. It should be removed now. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, June 2, 2021 1:30 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn<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 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] Questions about psa crypto persistent key

by Edward Yang

Hi Sherry, Import persistent key with a specified key_id is indeed supported in the updated crypto spec.. I mean,if a key created by derivation functions,and this key is imported as a persistent key with s specific key id such as KEY_ID_EXAMPLE,then this key is stored in internal Flash with its service. After the reset,this persistent key still exists,but this persisten key cannot be used to do encryption directly,for example,call psa_aead_encrypt(KEY_ID_EXAMPLE,alg,nonce,...),unless import this key with psa_import() once again. Call psa_aead_encrypt(SSKEY_ID,alg,nonce,...) without calling psa_import_key() in advance is not allowed,because in tfm_crypto_check_handle_owner()(why this API is needed?)it will check this key_id with handle_owner[] array. So I am wondering what's the intended use of persistent keys? After creation, this persistent keys can only be used to derive other encryption keys,rather than used to encrypt data with themselves? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn Sherry Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2021/06/02 17:37 Please respond to Sherry Zhang <Sherry.Zhang2(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject Re: [TF-M] Questions about psa crypto persistent key Hi Poppy, Some feedback from my understanding on the first question. 1. Import persistent key with a key_id is still supported in the updated PSA crypto spec. In the version of PSA crypto spec in which psa_open_key is supported, the persistent key can be opened after the reset with the key_id which is specified in the key attributes in key creation. This is not very friendly. The reason is that each time the user calls the psa_open_key, the crypto service loads the key material from slot to running area(ram or flash) thus a new associated resources is allocated. The application must eventually call psa_close_key to release the allocated associated resources. It can happen that multiple applications call psa_open_key multile times as they may do not know whether the key is opened by other applications. So it can happen that multiple copies of associated resources are allocated for the same key. This is not user friendly. In the updated PSA crypto spec, the key material management strategy is changed. The user does not need to call the psa_open_key to load the key from slot to ram/flash. See the section of “9.4 Key identifies” of the spec: ``` Key identifiers are output from a successful call to one of the key creation functions. For persistent keys, this is the same identifier as the one specified in the key attributes used to create the key. The key indenter remains valid until it is invalidated by passing it to psa_destroy_key(). A volatile key identifier must not be used after it has been invalidated. ``` So I think the user can use the key_id directly to call crypto operations, such as means encrypt, decrypt. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, June 2, 2021 1:30 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? 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 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. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m ============================================================================ 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

2
1
0 0

Re: [TF-M] Questions about psa crypto persistent key

by Edward Yang

Hi Andrew, “built-in keys with a pre-defined key_id” ,I take this to mean that HUK is a built-in key with the pre-defined key_id TFM_CRYPTO_KEY_ID_HUK,which can be stored in OTP,EEPROM or embedded Flash of MCU. There is no ownership of these built-in keys,however,application persisten keys are created by an application,so application persisten keys are owned by relevant applications. Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn Andrew Thoelke via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2021/06/02 17:33 Please respond to Andrew Thoelke <Andrew.Thoelke(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>, nd <nd(a)arm.com> cc Subject Re: [TF-M] Questions about psa crypto persistent key Hi Poppy Wu, In the v1.0.0 PSA Crypto spec, key handles were removed, and keys are now always referred to by a key identifier. After creating a persistent key with a key_id specified by the application (by import, generation or derivation), the key can be used in a cryptographic operation by passing the key_id to the operation function. No key handles are needed anymore. See https://armmbed.github.io/mbed-crypto/html/api/keys/lifetimes.html#persiste… . An implementation can provide some built-in keys with a pre-defined key_id. Depending on the key attributes and policy, these can be used by an application in appropriate cryptographic operations. Built-in keys can behave differently to application persistent keys: They cannot be destroyed by an application They might be accessible to multiple applications They might have different values in different applications The implementation should provide documentation on the expected use of any built-in keys. We’ll need one of the TF-M team to comment on the expected use for TFM_CRYPTO_KEY_ID_HUK. Regards, Andrew Thoelke Andrew Thoelke Software Systems Architect | Arm . . . . . . . . . . . . . . . . . . . . . . . . . . . Arm.com From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 02 June 2021 06:30 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? 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 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. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m ============================================================================ 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

Technical Forum call - June 10

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, June 10, 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

Re: [TF-M] Questions about psa crypto persistent key

by Sherry Zhang

Hi Poppy, Some feedback from my understanding on the first question. 1. Import persistent key with a key_id is still supported in the updated PSA crypto spec. In the version of PSA crypto spec in which psa_open_key is supported, the persistent key can be opened after the reset with the key_id which is specified in the key attributes in key creation. This is not very friendly. The reason is that each time the user calls the psa_open_key, the crypto service loads the key material from slot to running area(ram or flash) thus a new associated resources is allocated. The application must eventually call psa_close_key to release the allocated associated resources. It can happen that multiple applications call psa_open_key multile times as they may do not know whether the key is opened by other applications. So it can happen that multiple copies of associated resources are allocated for the same key. This is not user friendly. In the updated PSA crypto spec, the key material management strategy is changed. The user does not need to call the psa_open_key to load the key from slot to ram/flash. See the section of "9.4 Key identifies" of the spec: ``` Key identifiers are output from a successful call to one of the key creation functions. For persistent keys, this is the same identifier as the one specified in the key attributes used to create the key. The key indenter remains valid until it is invalidated by passing it to psa_destroy_key(). A volatile key identifier must not be used after it has been invalidated. ``` So I think the user can use the key_id directly to call crypto operations, such as means encrypt, decrypt. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, June 2, 2021 1:30 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn<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 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] Questions about psa crypto persistent key

by Andrew Thoelke

Hi Poppy Wu, In the v1.0.0 PSA Crypto spec, key handles were removed, and keys are now always referred to by a key identifier. After creating a persistent key with a key_id specified by the application (by import, generation or derivation), the key can be used in a cryptographic operation by passing the key_id to the operation function. No key handles are needed anymore. See https://armmbed.github.io/mbed-crypto/html/api/keys/lifetimes.html#persiste…. An implementation can provide some built-in keys with a pre-defined key_id. Depending on the key attributes and policy, these can be used by an application in appropriate cryptographic operations. Built-in keys can behave differently to application persistent keys: * They cannot be destroyed by an application * They might be accessible to multiple applications * They might have different values in different applications The implementation should provide documentation on the expected use of any built-in keys. We'll need one of the TF-M team to comment on the expected use for TFM_CRYPTO_KEY_ID_HUK. Regards, Andrew Thoelke Andrew Thoelke Software Systems Architect | Arm . . . . . . . . . . . . . . . . . . . . . . . . . . . Arm.com From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 02 June 2021 06:30 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Questions about psa crypto persistent key Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn<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 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

PEM format is enabled in crypto service by default

by Sherry Zhang

Hi, I want to talk about whether TFM should support the PEM key format in crypto operation. In the PSA crypto spec, it describes: ``` This specification supports a single format for each key type. Implementations may support other formats as long as the standard format is supported. ``` The PEM format is not the standard format described in the spec. However, in the tfm_mbedcrypto_config_default.h, the MBEDTLS_PEM_PARSE_C and the MBEDTLS_PEM_WRITE_C is defined which leads to that PEM key format operation is enabled in TFM crypto service. In isolation level1, about more than 2000 bytes code is introduced by this feature: .ER_TFM_CODE 0x2a01c // MBEDTLS_PEM_PARSE_C and the MBEDTLS_PEM_WRITE_C enabled .ER_TFM_CODE 0x29848 // MBEDTLS_PEM_PARSE_C and the MBEDTLS_PEM_WRITE_C disabled Is it necessary to support the PEM format in the key operation in crypto service at the cost of more than 2000 bytes? Any comments on that? Regards, Sherry Zhang

4 years, 5 months

1
0
0 0

Questions about psa crypto persistent key

by Edward Yang

Hi Experts, I have some questions about crypto persisten keys. 1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly. 2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code. tfm_plat_get_huk_derived_key(){ get HUK from OTP || || \/ how to derive crypto key from HUK with calling crypto service? } 3. BTW,HUK has a persistent key id TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK? 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 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] Technical Forum call - May 27

by Anton Komlev

Hi, The agenda for the forum: 1. Linker script/scatter file templating (Ken Liu) 2. Discussion on Non-Secure Client ID update (David Wang). 3. AOB Regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, May 19, 2021 6:21 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - May 27 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

Re: [TF-M] Firmware update API - MCUboot update

by Andrew Thoelke

Hi Suresh, > I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition. Are you suggesting that the software stack might look like this: Update client application | | Function call V MCUBoot user API Shim layer | | Function call V FWU API | | TF-M psa_call() etc. V FWU Partition | | Function call V MCUBoot user API MCUBoot engine This looks like it has one more layer than it needs, as either: 1. The Update client application could Talk directly to the FWU API, or 2. The first MCUBoot user API could interact with an MCUBoot update partition (RoT Service), without having to tunnel the MCUBoot API over the FWU API. The latter might not be straightforward - I am not sure that anyone has reviewed the two APIs for this purpose. Are you only considering this software stack for a system where touching the update client application source code is not possible (needed for option #1 above)? - and you also cannot introduce a custom MCUBoot RoT Service partition (option #2 above) so you want to reuse TF-M's existing FWU API and partition? Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: 25 May 2021 02:37 To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Firmware update API - MCUboot update Hi Sherry, Thanks for the info. Wondering if there is some documentation or powerpoint explaining how the MCUBoot is changed to accommodate the FWU API. Details that would help: 1. How the MCUboot works without the FWU API - natively 2. How the MCUBoot needs to be modified to leverage from FWU API 3. What components are retained in MCUBoot ex: image format, signing, metadata, tools I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition. The other way to look at it is: If somebody wants to replace MCUboot with a simple BL to integrate it tightly into TFM, what would that look like? thanks Suresh Marisetty Infineon Semiconductor Corporation From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Thursday, May 13, 2021 7:51 PM 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: Firmware update API - MCUboot update 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, The MCUboot update functionality is about validating the existing images on the device which is different from that of the firmware update service which follows mostly with the PSA Firmware Update API spec<https://developer.arm.com/documentation/ihi0093/latest/>. We designed a shim layer between the firmware update partition and bootloader. A specific bootloader can be ported into the firmware update partition via that shim layer. Please refer to the firmware update service document<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…>. In the MCUboot based shim layer implementation, it calls some user/public APIs provided by MCUboot to achieve its functionality. For example, the Firmware Update API spec describes that psa_fwu_install() API should validate the image or defer the validation to a system reboot. In the MCUboot shim layer implementation, it calls the boot_write_magic() API to mark the image as a candidate image for MCUboot and defers the image validation to a system reboot. Please refer to this link<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>. Can you please provide more specific suggestion or questions? Regards, Sherry Zhang From: Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com> <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>> Sent: Thursday, May 13, 2021 11:40 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@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: Firmware update API - MCUboot update Hi Sherry, Please take a closer look at the MCUboot and TFM might want to have a clear position/distinction between these two and how to transition from MCUboot update to this mechanism or it could be that they complement each other. thanks Suresh Marisetty Infineon Semiconductor Corporation From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Wednesday, May 12, 2021 8:55 PM 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: Firmware update API - MCUboot update 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, The firmware update service APIs are for updating the firmware. The functionalities of these APIs includes loading the image into its target device(flash), verifying the image and installing it and so on. The user can call the these APIs to achieve update images. For example, in the integration of TF-M and the FreeRTOS OTA<https://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractio…>, the OTA agent calls the firmware update service APIs to achieve an image update remotely. I guess that the "MCUboot update services" you mentioned refers to the functionality of MCUboot which acts as a bootloader. As a bootloader, it can verify the image which already exists on the device and chose the right image to start up. But it cannot, for example, load the image into device or control the image update process. The firmware update partition calls some user APIs provided by MCUboot to cooperate with it. You can refer to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…. Regards, Sherry Zhang 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 11:09 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Firmware update API - MCUboot update 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

2
1
0 0

Re: [TF-M] Firmware update API - MCUboot update

by Sherry Zhang

Hi Suresh, The firmware update service APIs are for updating the firmware. The functionalities of these APIs includes loading the image into its target device(flash), verifying the image and installing it and so on. The user can call the these APIs to achieve update images. For example, in the integration of TF-M and the FreeRTOS OTA<https://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractio…>, the OTA agent calls the firmware update service APIs to achieve an image update remotely. I guess that the "MCUboot update services" you mentioned refers to the functionality of MCUboot which acts as a bootloader. As a bootloader, it can verify the image which already exists on the device and chose the right image to start up. But it cannot, for example, load the image into device or control the image update process. The firmware update partition calls some user APIs provided by MCUboot to cooperate with it. You can refer to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: Thursday, May 13, 2021 11:09 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Firmware update API - MCUboot update 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

2
4
0 0

Re: [TF-M] A question on tfm its filesystem

by David Hu

Hi Poppy, SPRT requires the shared library shall not own static R/W data. ITS filesystem may not satisfy this requirement. Usually, a SP, for example Protected Storage, can rely on ITS service to access data in non-volatile memory. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Monday, May 24, 2021 12:54 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] A question on tfm its filesystem 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, 5 months

2
2
0 0

Wiki page sorting out

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

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

by David Hu

Hi Suresh, Secure Enclave and dual-cpu so far only support IPC model. Therefore Profile Medium and Profile Large can run on SE and dual-cpu platforms. Besides, Profile Large by default enables Fault Injection Hardening library. It requires platform to support Fault Injection Hardening. The secure firmware binary size may vary with different underlying inter-core communication and assigned resources. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Friday, April 30, 2021 3:40 PM To: Suresh.Marisetty(a)infineon.com; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Questions on Musca-B1 SE implementation 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, 6 months

1
0
0 0

Questions on Musca-B1 SE implementation

by Suresh.Marisetty＠infineon.com

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

1
0
0 0

Re: [TF-M] Decouple NS specific code from TF-M NS interface

by David Hu

Hi all, The patch sets to decouple NS code from TF-M secure part have been merged. Sorry for the early merge as other pending patches depend on this patch set. Please rebase your patches if build reports an error about conflicting types of `tfm_ns_interface_init()`. Sorry for any inconvenience. If this decoupling brings any issue in NS integration with TF-M, sorry about the trouble and I'd appreciate it if you can share the issue details. Any further comment or suggestion is welcome. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, April 27, 2021 11:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface Hi all, Thanks a lot for all your review and comments! I'd like to merge the patch sets *this Friday* if there is no further critical comment. Please feel free to continue to review and comment. Best regards, Hu Ziji 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: Thursday, April 15, 2021 4:12 PM 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] [Ask for review] Decouple NS specific code from TF-M NS interface Hi all, May I ask you to take a look at the following patch set to decouple NS specific code from TF-M NS interface? https://review.trustedfirmware.org/q/topic:%22decouple-ns-interface%22+(sta… The decoupled NS code is moved from trusted-firmware-m repo to tf-m-tests repo, as an example of NS implementation. https://review.trustedfirmware.org/q/topic:%22add-ns-code%22+(status:open%2… The purpose of this change is to make it more flexible and simple to integrate NS OS with TF-M NS interface. Currently TF-M provides some reference implementations of NS interface for NS OS integration. However, it may have limitations during NS OS integration as various NS OSes/application usages prefer different implementations. Therefore, those NS OS specific code is removed from TF-M interface for NS clients in this patch set. The removed NS code includes NS interface lock ops, os wrappers and NS test specific implementation. Those NS code can be taken as an example in tf-m-tests. NS developers can follow or replace them during integration with TF-M, according to NS OS implementation and actual scenarios, without hacking trusted-firmware-m repo. This patch set doesn't change the current integration scheme. Instead, it exports the "tfm_ns_interface_dispatch()" API and enables NS OS to implement it according to NS OS and application specific requirement, such as NS interface lock operations. Any comment is welcome! Best regards, Hu Ziji

4 years, 6 months

1
0
0 0

Re: [TF-M] Technical Forum call - April 29

by Anton Komlev

Hi, We have no explicit items in the agenda. Let's use this chance to discuss any ongoing topics and questions like: * Planning repo restructuring * S <> NS decoupling * Pended PS reviews and a need for clarification * Your topic See you, Anton 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: Wednesday, April 21, 2021 11:40 PM 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 - April 29 Hi, The next Technical Forum is planned on Thursday, April 29 , 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, 6 months

1
0
0 0

Re: [TF-M] Supporting integrated Non-Secure RTOS applications that use the FPU

by Feder Liang

Hi, Ioannis Sorry for late response. I am out of office these two days. Thank you very much for sharing your problem here. As Keven mentioned, could you please report your problem on phabricator first with more details? This will be very helpful for us to analyze the problem you mentioned. 1. Which cortex-m core? 2. TF-M changeset you are using and compiler version. 3. Please list all changes you did for TF-M while integrated to your project. 4. More information about the crash: * IPC mode, right? Which isolation level? * Detail sequences of actions between NS and S when crash. * Lzay FP enabled? Crash when FPCCR_NS.LSPACT = 1 or something else? * Which PSA calls causes the crash, or all PSA calls? * How about the occurrence of crash? Always crash or sometimes? * Which fault entered? Value of registers and stack frame in memory at crash time are very useful for analysis. * ……., Other information if possible. The more information the better, please try to attached them in phabricator. Thank you. Best Regards Feder From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Glaropoulos, Ioannis via TF-M Sent: Thursday, April 22, 2021 3:24 PM To: Kevin Townsend (kevin.townsend(a)linaro.org) <kevin.townsend(a)linaro.org>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Supporting integrated Non-Secure RTOS applications that use the FPU Hi Kevin, Thanks for the link to the presentation 😊 I guess, then, Feder Liang, as the author of the presentation, should be able to provide some feedback on the questions I raised? Once more, I am stressing that our questions concern the usage of FPU in Non-Secure applications that integrate with TF-M today; it is not about future improvements for FPU support inside TF-M, which was (I guess) the main point of this presentation. Best, Ioannis From: Kevin Townsend <kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>> Sent: Wednesday, April 21, 2021 8:03 PM To: Glaropoulos, Ioannis <Ioannis.Glaropoulos(a)nordicsemi.no<mailto:Ioannis.Glaropoulos@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting integrated Non-Secure RTOS applications that use the FPU On Wed, 21 Apr 2021 at 18:56, Glaropoulos, Ioannis via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: I would like to ask the community whether these issues have been raised in the past – and if so, please, inform me what the conclusions have been. Are there current activities that attempt to address the problems raised above? Not been able to fully utilize the FP context stacking in Non-Secure Zephyr applications that integrate with TF-M removes value of our TF-M based solutions. Thanks! I am looking forward to hearing the thoughts of the community. Hi Ioannis, The previous technical forum call did discuss FP usage ... I don't think you were on the call at the time, but the presentation and video can be viewed here, and should point to the people to follow up with here on the mailing list of on phabricator, etc. Presentation: https://www.trustedfirmware.org/docs/FP-support-in-TF-M.pdf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.trust…> Video link(s) available here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.trust…> Best rehards, Kevin

4 years, 6 months

2
1
0 0

Re: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface

by David Hu

Hi all, Thanks a lot for all your review and comments! I'd like to merge the patch sets *this Friday* if there is no further critical comment. Please feel free to continue to review and comment. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, April 15, 2021 4:12 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface Hi all, May I ask you to take a look at the following patch set to decouple NS specific code from TF-M NS interface? https://review.trustedfirmware.org/q/topic:%22decouple-ns-interface%22+(sta… The decoupled NS code is moved from trusted-firmware-m repo to tf-m-tests repo, as an example of NS implementation. https://review.trustedfirmware.org/q/topic:%22add-ns-code%22+(status:open%2… The purpose of this change is to make it more flexible and simple to integrate NS OS with TF-M NS interface. Currently TF-M provides some reference implementations of NS interface for NS OS integration. However, it may have limitations during NS OS integration as various NS OSes/application usages prefer different implementations. Therefore, those NS OS specific code is removed from TF-M interface for NS clients in this patch set. The removed NS code includes NS interface lock ops, os wrappers and NS test specific implementation. Those NS code can be taken as an example in tf-m-tests. NS developers can follow or replace them during integration with TF-M, according to NS OS implementation and actual scenarios, without hacking trusted-firmware-m repo. This patch set doesn't change the current integration scheme. Instead, it exports the "tfm_ns_interface_dispatch()" API and enables NS OS to implement it according to NS OS and application specific requirement, such as NS interface lock operations. Any comment is welcome! Best regards, Hu Ziji

4 years, 6 months

1
0
0 0

Temporary moving 'tfm_spm_hal_configure_default_isolation' out of FIH mointoring

by Ken Liu

Hi, We are refining the HAL logics for MMIO, so this legacy API 'tfm_spm_hal_configure_default_isolation', which is now monitored under FIH library would be out of monitoring for a while. The successors for this API would be added back after the refining is done, unless there are coming FIH updates. Moving this single function out of FIH monitoring won't trigger problems - in most of the cases this API just returns without actions as few partition has bound MMIOs. Thanks. /Ken

4 years, 6 months

1
0
0 0

[Partition and Build] Partition storage arrangement patches

by Ken Liu

Hi, As we planned some time ago in one of the Tech Forums about updating the partition storage (Search "TF-M Partition Storage Arrangement" here:https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ ), we have created several patches to complete this. Here in this mail is to broadcast that the partition storage would get updated after this patch, the loading process in SPM would be updated as well to provide: * Better modularization, especially for partitions. Now the partition info are put inside sections, hence there is no source level dependencies in SPM. When partitions get added/removed during one build it won't trigger a build of SPM library. * Clear interface for future expansion, such as other partition loading mechanism, for example, a partition saved in a non-XIP flash or else. But at current stage we still focus on storing partition in XIP based ROM. Some intermedia patches can't be perfect during the movement, so please focus on the final result of patch groups instead of focusing to make one of the staging patches perfect - we don't want to create a big patch hence some trade-off-like patches have to be there. The patches can be found here: https://review.trustedfirmware.org/q/topic:%22partition_storage%22+(status:… Feel free to comment and provide ideas! BR /Ken

4 years, 6 months

1
0
0 0

Re: [TF-M] Supporting integrated Non-Secure RTOS applications that use the FPU

by Anton Komlev

This is a test message. I know that Feder have posted to the list but message was not delivered. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Thursday, April 22, 2021 11:31 AM To: Glaropoulos, Ioannis <Ioannis.Glaropoulos(a)nordicsemi.no> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Supporting integrated Non-Secure RTOS applications that use the FPU On Thu, 22 Apr 2021 at 09:23, Glaropoulos, Ioannis <Ioannis.Glaropoulos(a)nordicsemi.no<mailto:Ioannis.Glaropoulos@nordicsemi.no>> wrote: Once more, I am stressing that our questions concern the usage of FPU in Non-Secure applications that integrate with TF-M today; it is not about future improvements for FPU support inside TF-M, which was (I guess) the main point of this presentation. Looking at this a bit further it is indeed a serious issue, since most modern applications are going to want to make use of the FPU. This prevents the FPU from being used inside NS interrupts as well. I’m not sure if there are currently any change requests that identify or fix this problem (I’ll look), but it’s something that should have some sort of test on the NS side, for sure. Do you mind filing the details on TF-M’s phabricator and it can more easily be tracked there? Thanks for bringing this up, Kevin

4 years, 6 months

1
0
0 0

Re: [TF-M] Supporting integrated Non-Secure RTOS applications that use the FPU

by Kevin Townsend

On Wed, 21 Apr 2021 at 18:56, Glaropoulos, Ioannis via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > I would like to ask the community whether these issues have been raised in > the past – and if so, please, inform me what the conclusions have been. Are > there current activities that attempt to address the problems raised above? > Not been able to fully utilize the FP context stacking in Non-Secure Zephyr > applications that integrate with TF-M removes value of our TF-M based > solutions. > > > > Thanks! I am looking forward to hearing the thoughts of the community. > > Hi Ioannis, The previous technical forum call did discuss FP usage ... I don't think you were on the call at the time, but the presentation and video can be viewed here, and should point to the people to follow up with here on the mailing list of on phabricator, etc. Presentation: https://www.trustedfirmware.org/docs/FP-support-in-TF-M.pdf Video link(s) available here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best rehards, Kevin

4 years, 6 months

2
2
0 0

Removal of the nRF5340 PDK platform

by Głąbek, Andrzej

Hello, As announced on March 3 (see https://lists.trustedfirmware.org/pipermail/tf-m/2021-March/001516.html) and in the absence of objections, the nRF5340 PDK platform (nordic_nrf/nrf5340pdk_nrf5340_cpuapp) has been deprecated in the v1.3.0 release and the release is the last one to support this platform. Today, the code and documentation related to this platform have been removed from TF-M. Best regards, Andrzej Głąbek

4 years, 6 months

1
0
0 0

Re: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface

by Anton Komlev

Hi, Here is the proposal to restructure TF-M following the intention to split it on the essential part and supplementary items with better logical separation. The proposed new structure, composed from 4 repositories is following: 1. trusted-firmware-m (The essential TF-M core: SPM + PSA partitions and interface. Documentation) 2. tf-m-tests * regression * other test 3. tf-m-tools (additional tools and place for integration glue with 3rd party frameworks) * cmsis * fuzzer * Iat-verifier * ... 4. tf-m-extras (extra components, used in a specific case, but optional for common use) * examples i. NS ii. S * S-partitions - (3rd party production partitions) The questions to the community: 1. Any concern or dependency on the proposed restructure? 2. Shall we treat tests separately or as one of the extra component? Effectively the question are tests deserves a dedicated repo or a folder in tf-m-extra? 3. Better name for tf-m-extra? tf-m-apps? Looking for your comments, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, April 15, 2021 12:24 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface Thanks, David, The connected job is to rename tf-m-tests repo to something more general to keep supplementary code and not interfere it with TF-M core on secure side. The first candidate was tf-m-ns to reflect the collection of non-secure elements but it might confuse when using it for custom and examples of secure partitions. Thoughts and proposals for the repo naming are welcome. Regards, Anton 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: Thursday, April 15, 2021 9:12 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: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface Hi all, May I ask you to take a look at the following patch set to decouple NS specific code from TF-M NS interface? https://review.trustedfirmware.org/q/topic:%22decouple-ns-interface%22+(sta… The decoupled NS code is moved from trusted-firmware-m repo to tf-m-tests repo, as an example of NS implementation. https://review.trustedfirmware.org/q/topic:%22add-ns-code%22+(status:open%2… The purpose of this change is to make it more flexible and simple to integrate NS OS with TF-M NS interface. Currently TF-M provides some reference implementations of NS interface for NS OS integration. However, it may have limitations during NS OS integration as various NS OSes/application usages prefer different implementations. Therefore, those NS OS specific code is removed from TF-M interface for NS clients in this patch set. The removed NS code includes NS interface lock ops, os wrappers and NS test specific implementation. Those NS code can be taken as an example in tf-m-tests. NS developers can follow or replace them during integration with TF-M, according to NS OS implementation and actual scenarios, without hacking trusted-firmware-m repo. This patch set doesn't change the current integration scheme. Instead, it exports the "tfm_ns_interface_dispatch()" API and enables NS OS to implement it according to NS OS and application specific requirement, such as NS interface lock operations. Any comment is welcome! Best regards, Hu Ziji

4 years, 6 months

1
0
0 0

Technical Forum call - April 29

by Anton Komlev

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

1
0
0 0

Supporting integrated Non-Secure RTOS applications that use the FPU

by Glaropoulos, Ioannis

Hi, I would like to raise an issue around Floating Point support in the context of Non-Secure RTOS-based applications integrated with TF-M. The problem: We cannot fully (and easily) utilize the cortex-m Floating point features in Zephyr running together with TF-M. (Note, this has little to do with TF-M not having a secure floating point support today - we focus entirely on using the FPU in non-secure domain.) Description of the case: In Zephyr multi-thread environment we enable the FP co-processor and the advanced context-control features in Cortex-M * Automatic state preservation * Lazy stacking Zephyr threads are free to use the floating point registers; the automatic state preservation ensures the caller-saved registers are preserved and the context-switch routines ensure the callee-saved registers are preserved as well. The situation becomes interesting when Zephyr threads with active FP context are doing calls to the TF-M services. In such a scenario, it may happen that the TF-M secure threads will need to preserve the FP context themselves, during a non-secure interrupt that accesses the FP registers. Currently this triggers a TF-M system crash, as TF-M does not enable the FP co-processor. I guess this could be solved by enabling the FP co-processor in TF-M. Even in this case, the TF-M would need to preserve the FP context state when switching between threads in Secure PendSV, so Non-Secure interrupts (and potential Non-Secure reschedule actions) would not interfere with FP state preservation. What we see today is that the Non-Secure FP context is not preserved during TF-M thread switches, leading to weird situations such as when the lazy state preservation active bit is set in Secure thread mode; which should not be the case. I would like to ask the community whether these issues have been raised in the past - and if so, please, inform me what the conclusions have been. Are there current activities that attempt to address the problems raised above? Not been able to fully utilize the FP context stacking in Non-Secure Zephyr applications that integrate with TF-M removes value of our TF-M based solutions. Thanks! I am looking forward to hearing the thoughts of the community. Ioannis

4 years, 6 months

1
0
0 0

Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification

by Kevin Peng

Hi Andrew, - Are there other important uses for the query API? I cannot really answer this question. But as you have mentioned, when this query API is provided, it couldn't be always reliable - the status could be changed between query and control. And I also think the nested critical section could really happen (this was the main use case of the IRQ status I guess): A Partition thread and a FLIH function for IRQ1 both wants to mask IRQ2 because they both have data shared with IRQ2. This means the IRQ1 and Partition thread have shared data. Then the Secure Partition thread should mask both IRQ1 and IRQ2 when it accesses the shared data. So IMHO, I don't think Secure Partitions need to the status of IRQs. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M Sent: Wednesday, April 14, 2021 6:15 PM To: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification Hi Kevin, In light of the concern regarding atomicity and race conditions, is there a real benefit to retaining the behaviour of psa_irq_disable() returning the prior status. By defining the API this way, it forces every implementation to ensure that the test-and-disable action of this API is atomic with respect to all interrupts in the system (as these could modify the target interrupt state between the test and the disable). Even if TF-M today does this as a result of using an SVC to implement this API, that does not imply that all implementations will need to do that. If we remove the return value from psa_irq_disable(), this also simplifies the TF-M implementation using the CMSIS NVIC_DisableIRQ() function. This would leave us with: void psa_irq_enable(psa_signal_t irq_signal); void psa_irq_disable(psa_signal_t irq_signal); Is it problematic to provide no mechanism to query the state? Are the following use cases for psa_irq_is_enabled() important enough to include this API: * Diagnostics (e.g. when debugging) * Initialisation * Recovery from error conditions The last two of these shouldn't require such an API, as the software should be aware of the peripheral and interrupt state at these points - but the API might make coding these easier? Are there other important uses for the query API? Regards, Andrew -----Original Message----- From: Kevin Peng <Kevin.Peng(a)arm.com> Sent: 13 April 2021 05:03 To: Andrew Thoelke <Andrew.Thoelke(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: Arm Firmware Framework for M 1.1 Extensions Alpha specification Hi Andrew, [Sorry for the long delay of resuming this discussion.] I think psa_irq_is_enabled() could be removed. As the peripherals are exclusively owned by Partitions, Partitions should be able to manage the status of the IRQs by themselves. And the psa_irq_disable() could still return the previous status. It (and the psa_irq_enable() as well) should be atomic anyway because the caller would consider the IRQ is disabled or enabled by calling the corresponding API. The APIs must ensure the validness, to do that disabling interrupts entirely might be inevitable. In TF-M, this is done by calling SVC in the APIs to tell SPM to manipulate the interrupt controller. And SVC has higher priority than all interrupts. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M Sent: Monday, February 22, 2021 11:03 PM To: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification I've had some further input on the interrupt management API. The use of patterns such as: bool irq_enabled = psa_irq_is_enabled(MY_IRQ); // [1] psa_irq_disable(MY_IRQ); // [2] // critical section if (irq_enabled) psa_irq_enable(MY_IRQ); must be discouraged as this is not guaranteed to be safe in the presence of interrupts that can change the status of MY_IRQ between the query [1] and the disable [2]. In general, it requires whole system analysis to determine that there are no such interrupts, and that this code is 100% reliable. However, providing the originally proposed API such as psa_irq_disable(), which returns the prior status, does not practically solve the problem. Instead, it just moves the race condition window into the implementation of that API. The only way in which such an API would be generally safe from the race condition is if the query+disable is atomic with respect to all other interrupts in the system - this either requires disabling interrupts entirely, or having an atomic read+disable capability in the interrupt controller. In systems which worry about such race conditions, disabling all interrupts can be unacceptable. The recommended approach is to avoid having software that depends on the state of the interrupt, but which does not implicitly know the state of the interrupt. In such a system, there is never a need to query the current interrupt state as on any line of code, the interrupt state is always known at design time. I am not sure if this suggests that we should: 1. Remove even the psa_irq_is_enabled() function, to prevent developers writing the above code, OR 2. We do not document the above pattern as a way to manage nested critical sections, OR 3. Retain the example above, but explain that this must be coupled with a software design that ensures the stability of the MY_IRQ status between [1] and [2]? Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 22 February 2021 04:49 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification As the ‘psa_irq_status_t’ is a implementation-defined value, is it possible let the implementation-define the status encoding? Then the status and its checking code needs to be define by implementation, too: PSA_IRQ_STATUS_NOCHANGE PSA_IRQ_STATUS_DISABLE PSA_IRQ_STATUS_ENABLE PSA_IRQ_STAUTS_IS_ENABLED(status) This would make everything implementation-defined and this affects the headers, and one extra header: psa_impdef.h needs to be created by implementations. With this the ffm based applications just use preprocessors to get status and check them; the enable/disable can be out of ‘true’ and ‘false’ values. /Ken From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Tuesday, January 26, 2021 11:08 AM To: mailto:tf-m@lists.trustedfirmware.org Cc: nd <mailto:nd@arm.com> Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification Hi all, Per the off-line discussion with Andrew, I’d like to start a wider discussion on the interrupt APIs, specifically the Secure Partition API changes for interrupt control in chapter 6.3.3. There are the following APIs: • uint32_t psa_irq_is_enabled (psa_signal_t irq_signal); This API returns 0 if the interrupt is disabled and 1 if the interrupt is enabled. • psa_irq_status_t psa_irq_disable(psa_signal_t irq_signal); This API returns the status of the interrupt prior to this call with an implementation defined value Note the return type of the interrupt status is different. The first one is only to tell whether the interrupt is enabled (1) or not (0) – an equivalent to bool type. The second one could be any value to indicate an interrupt status. And that value is intended to be passed to psa_irq_restore to write to the interrupt control register directly. • void psa_irq_restore(psa_signal_t irq_signal, psa_irq_status_t saved_status); The typical usage: psa_irq_status irq2_state = psa_irq_disable(IRQ2_SIGNAL) ; // manipulate data shared with IRQ2 … psa_irq_restore(IRQ2_SIGNAL, irq2_state); This is a very efficient design as the 'saved status value' can be the exact value that needs to be written to an interrupt control register to restore the previous state. But TF-M seems to be unable to take that advantage. Because the most common interrupt controller is the NVIC provided by the core. The NVIC takes 1/0 to enable or disable the interrupt and one register for 32 interrupts. The underlying NVIC operation provided by CMSIS is NVIC_Enable/DisableIRQ. So the psa_irq_status_t in TF-M would simply 1 or 0 for a specific interrupt signal. Then the psa_irq_restore could be unnecessary if psa_irq_disable returns uint32_t just like psa_irq_is_enabled: uint32_t irq_status = psa_irq_disable(IRQ); ... // critical section if (irq_status) psa_irq_enable(IRQ); Any thoughts on the necessity of the psa_irq_restore API? The draft implementation of the current APIs for easy understanding: https://review.trustedfirmware.org/q/topic:%22psa_interrupt_api%22+(status:… Best Regards, Kevin -----Original Message----- From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M Sent: Friday, January 15, 2021 1:25 AM To: mailto:tf-m@lists.trustedfirmware.org; nd <mailto:nd@arm.com> Subject: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification Hi all, The PSA Firmware Framework for M 1.1 Extensions specification is now published on Arm Developer. This document introduces a set of updates and extensions to the Arm® Platform Security Architecture Firmware Framework (FF-M) specification, designed to build on the capabilities provided in version 1.0. This is an initial ALPHA release in order to enable wider review and feedback on the changes proposed to be included in the v1.1 specification. At this quality level, the changes and interfaces defined are not stable enough for product development. When the proposed extensions are sufficiently stable to be classed as Beta, they will be integrated into the FF-M version 1.1 specification. The 1.1 Extensions document can be downloaded from: https://developer.arm.com/documentation/aes0039/latest Both the 1.0 Specification and the 1.1 Extensions document are linked from the main PSA architecture page: https://developer.arm.com/architectures/security-architectures/platform-sec… Ken and I have presented a number of times at last year's Tech Forums on the proposals in the specification, most recently I provided a summary of the whole document on 10th December 2020. If you have any feedback, please provide it to mailto:arm.psa-feedback@arm.com, or discuss the proposals here in the TF-M mailing list. Regards, Andrew -- TF-M mailing list mailto:TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- 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] [Ask for review] Decouple NS specific code from TF-M NS interface

by Anton Komlev

Thanks, David, The connected job is to rename tf-m-tests repo to something more general to keep supplementary code and not interfere it with TF-M core on secure side. The first candidate was tf-m-ns to reflect the collection of non-secure elements but it might confuse when using it for custom and examples of secure partitions. Thoughts and proposals for the repo naming are welcome. Regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, April 15, 2021 9:12 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface Hi all, May I ask you to take a look at the following patch set to decouple NS specific code from TF-M NS interface? https://review.trustedfirmware.org/q/topic:%22decouple-ns-interface%22+(sta… The decoupled NS code is moved from trusted-firmware-m repo to tf-m-tests repo, as an example of NS implementation. https://review.trustedfirmware.org/q/topic:%22add-ns-code%22+(status:open%2… The purpose of this change is to make it more flexible and simple to integrate NS OS with TF-M NS interface. Currently TF-M provides some reference implementations of NS interface for NS OS integration. However, it may have limitations during NS OS integration as various NS OSes/application usages prefer different implementations. Therefore, those NS OS specific code is removed from TF-M interface for NS clients in this patch set. The removed NS code includes NS interface lock ops, os wrappers and NS test specific implementation. Those NS code can be taken as an example in tf-m-tests. NS developers can follow or replace them during integration with TF-M, according to NS OS implementation and actual scenarios, without hacking trusted-firmware-m repo. This patch set doesn't change the current integration scheme. Instead, it exports the "tfm_ns_interface_dispatch()" API and enables NS OS to implement it according to NS OS and application specific requirement, such as NS interface lock operations. Any comment is welcome! Best regards, Hu Ziji

4 years, 6 months

1
0
0 0

[Ask for review] Decouple NS specific code from TF-M NS interface

by David Hu

Hi all, May I ask you to take a look at the following patch set to decouple NS specific code from TF-M NS interface? https://review.trustedfirmware.org/q/topic:%22decouple-ns-interface%22+(sta… The decoupled NS code is moved from trusted-firmware-m repo to tf-m-tests repo, as an example of NS implementation. https://review.trustedfirmware.org/q/topic:%22add-ns-code%22+(status:open%2… The purpose of this change is to make it more flexible and simple to integrate NS OS with TF-M NS interface. Currently TF-M provides some reference implementations of NS interface for NS OS integration. However, it may have limitations during NS OS integration as various NS OSes/application usages prefer different implementations. Therefore, those NS OS specific code is removed from TF-M interface for NS clients in this patch set. The removed NS code includes NS interface lock ops, os wrappers and NS test specific implementation. Those NS code can be taken as an example in tf-m-tests. NS developers can follow or replace them during integration with TF-M, according to NS OS implementation and actual scenarios, without hacking trusted-firmware-m repo. This patch set doesn't change the current integration scheme. Instead, it exports the "tfm_ns_interface_dispatch()" API and enables NS OS to implement it according to NS OS and application specific requirement, such as NS interface lock operations. Any comment is welcome! Best regards, Hu Ziji

4 years, 6 months

1
0
0 0

Re: [TF-M] Technical Forum call - April 15

by Feder Liang

Hi, Anton I would like to introduce the topic about "FP support in TF-M". It may take about 60 mins. Best Regards Feder From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, April 7, 2021 9:27 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - April 15 Hi, The next Technical Forum is planned on Thursday, April 15, 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

2
1
0 0

Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification

by Kevin Peng

Hi Andrew, [Sorry for the long delay of resuming this discussion.] I think psa_irq_is_enabled() could be removed. As the peripherals are exclusively owned by Partitions, Partitions should be able to manage the status of the IRQs by themselves. And the psa_irq_disable() could still return the previous status. It (and the psa_irq_enable() as well) should be atomic anyway because the caller would consider the IRQ is disabled or enabled by calling the corresponding API. The APIs must ensure the validness, to do that disabling interrupts entirely might be inevitable. In TF-M, this is done by calling SVC in the APIs to tell SPM to manipulate the interrupt controller. And SVC has higher priority than all interrupts. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M Sent: Monday, February 22, 2021 11:03 PM To: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification I've had some further input on the interrupt management API. The use of patterns such as: bool irq_enabled = psa_irq_is_enabled(MY_IRQ); // [1] psa_irq_disable(MY_IRQ); // [2] // critical section if (irq_enabled) psa_irq_enable(MY_IRQ); must be discouraged as this is not guaranteed to be safe in the presence of interrupts that can change the status of MY_IRQ between the query [1] and the disable [2]. In general, it requires whole system analysis to determine that there are no such interrupts, and that this code is 100% reliable. However, providing the originally proposed API such as psa_irq_disable(), which returns the prior status, does not practically solve the problem. Instead, it just moves the race condition window into the implementation of that API. The only way in which such an API would be generally safe from the race condition is if the query+disable is atomic with respect to all other interrupts in the system - this either requires disabling interrupts entirely, or having an atomic read+disable capability in the interrupt controller. In systems which worry about such race conditions, disabling all interrupts can be unacceptable. The recommended approach is to avoid having software that depends on the state of the interrupt, but which does not implicitly know the state of the interrupt. In such a system, there is never a need to query the current interrupt state as on any line of code, the interrupt state is always known at design time. I am not sure if this suggests that we should: 1. Remove even the psa_irq_is_enabled() function, to prevent developers writing the above code, OR 2. We do not document the above pattern as a way to manage nested critical sections, OR 3. Retain the example above, but explain that this must be coupled with a software design that ensures the stability of the MY_IRQ status between [1] and [2]? Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 22 February 2021 04:49 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification As the ‘psa_irq_status_t’ is a implementation-defined value, is it possible let the implementation-define the status encoding? Then the status and its checking code needs to be define by implementation, too: PSA_IRQ_STATUS_NOCHANGE PSA_IRQ_STATUS_DISABLE PSA_IRQ_STATUS_ENABLE PSA_IRQ_STAUTS_IS_ENABLED(status) This would make everything implementation-defined and this affects the headers, and one extra header: psa_impdef.h needs to be created by implementations. With this the ffm based applications just use preprocessors to get status and check them; the enable/disable can be out of ‘true’ and ‘false’ values. /Ken From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Tuesday, January 26, 2021 11:08 AM To: mailto:tf-m@lists.trustedfirmware.org Cc: nd <mailto:nd@arm.com> Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification Hi all, Per the off-line discussion with Andrew, I’d like to start a wider discussion on the interrupt APIs, specifically the Secure Partition API changes for interrupt control in chapter 6.3.3. There are the following APIs: • uint32_t psa_irq_is_enabled (psa_signal_t irq_signal); This API returns 0 if the interrupt is disabled and 1 if the interrupt is enabled. • psa_irq_status_t psa_irq_disable(psa_signal_t irq_signal); This API returns the status of the interrupt prior to this call with an implementation defined value Note the return type of the interrupt status is different. The first one is only to tell whether the interrupt is enabled (1) or not (0) – an equivalent to bool type. The second one could be any value to indicate an interrupt status. And that value is intended to be passed to psa_irq_restore to write to the interrupt control register directly. • void psa_irq_restore(psa_signal_t irq_signal, psa_irq_status_t saved_status); The typical usage: psa_irq_status irq2_state = psa_irq_disable(IRQ2_SIGNAL) ; // manipulate data shared with IRQ2 … psa_irq_restore(IRQ2_SIGNAL, irq2_state); This is a very efficient design as the 'saved status value' can be the exact value that needs to be written to an interrupt control register to restore the previous state. But TF-M seems to be unable to take that advantage. Because the most common interrupt controller is the NVIC provided by the core. The NVIC takes 1/0 to enable or disable the interrupt and one register for 32 interrupts. The underlying NVIC operation provided by CMSIS is NVIC_Enable/DisableIRQ. So the psa_irq_status_t in TF-M would simply 1 or 0 for a specific interrupt signal. Then the psa_irq_restore could be unnecessary if psa_irq_disable returns uint32_t just like psa_irq_is_enabled: uint32_t irq_status = psa_irq_disable(IRQ); ... // critical section if (irq_status) psa_irq_enable(IRQ); Any thoughts on the necessity of the psa_irq_restore API? The draft implementation of the current APIs for easy understanding: https://review.trustedfirmware.org/q/topic:%22psa_interrupt_api%22+(status:… Best Regards, Kevin -----Original Message----- From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M Sent: Friday, January 15, 2021 1:25 AM To: mailto:tf-m@lists.trustedfirmware.org; nd <mailto:nd@arm.com> Subject: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification Hi all, The PSA Firmware Framework for M 1.1 Extensions specification is now published on Arm Developer. This document introduces a set of updates and extensions to the Arm® Platform Security Architecture Firmware Framework (FF-M) specification, designed to build on the capabilities provided in version 1.0. This is an initial ALPHA release in order to enable wider review and feedback on the changes proposed to be included in the v1.1 specification. At this quality level, the changes and interfaces defined are not stable enough for product development. When the proposed extensions are sufficiently stable to be classed as Beta, they will be integrated into the FF-M version 1.1 specification. The 1.1 Extensions document can be downloaded from: https://developer.arm.com/documentation/aes0039/latest Both the 1.0 Specification and the 1.1 Extensions document are linked from the main PSA architecture page: https://developer.arm.com/architectures/security-architectures/platform-sec… Ken and I have presented a number of times at last year's Tech Forums on the proposals in the specification, most recently I provided a summary of the whole document on 10th December 2020. If you have any feedback, please provide it to mailto:arm.psa-feedback@arm.com, or discuss the proposals here in the TF-M mailing list. Regards, Andrew -- TF-M mailing list mailto:TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 6 months

2
1
0 0

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

by Tamas Ban

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] Timeframe on release/approval

by Jamie Mccrae

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> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: 13 April 2021 17:57 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)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> 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<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] Timeframe on release/approval

by Shebu Varghese Kuriakose

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<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] TF-M at Linaro Connect 2021

by Shebu Varghese Kuriakose

The video links to the TF-M presentations @ Linaro Virtual Connect 2021 can be found here - https://developer.trustedfirmware.org/w/tf_m/tf-m_videos/linaro_virtual_con… Thanks, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, March 18, 2021 3:58 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M at Linaro Connect 2021 Hello, This is the list of TF-M related sessions on Linaro Virtual Connect 2021 https://connect.linaro.org/schedule/ * 23/3 @ 17:15 Introducing the Trusted Services project - Julian Hall * 23/3 @ 18:30 Physical Attack Mitigation - Tamas Ban, Raef Coles * 24/3 @ 9:45 Firmware update service in TF-M - Sherry Zhang * 24/3 @ 10:45 Firmware Framework - M 1.1 feature update in TF-M - Ken Liu * 25/3 @ 12:45 X.509 Certificate Management with Zephyr/TF-M - David Vincze * 25/3 @ 13:15 Essential ARM Cortex-M Debugging with GDB - Kevin Townsend Cheers, Anton

4 years, 6 months

1
0
0 0

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

by David Hu

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<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] Timeframe on release/approval

by Minos Galanakis

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.

4 years, 6 months

1
0
0 0

Timeframe on release/approval

by Jamie Mccrae

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

TF-M v1.3.0 release

by Anton Komlev

Hello, TF-M project released version v1.3.0, tagged as TF-Mv1.3.0. Please take a look into the release notes for the new features and changes: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/refer… The major features: * Support stateless RoT Service defined in FF-M 1.1 * Support Second-Level Interrupt Handling (SLIH) defined in FF-M 1.1 * Add Firmware Update (FWU) secure service, following Platform Security Architecture Firmware Update API * Migrate to Mbed TLS v2.25.0 * Update MCUboot version to v1.7.2 * Add a TF-M generic threat model * Implement Fault Injection Handling library to mitigate physical attacks * Add Profile Large * Enable code sharing between boot loader and TF-M * Support Armv8.1-M Privileged Execute Never (PXN) attribute and Thread reentrancy disabled (TRD) feature * New platforms added * Add a TF-M security landing page * Enhance dual-cpu non-secure mailbox reference implementation This is the first release performed in the OpenCI infrastructure with no single issue encountered. Thanks to everyone who directly and indirectly contributed to this milestone. Anton Komlev TF-M technical lead Arm Ltd.

4 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M