- TF-M - lists.trustedfirmware.org

spi peripheral doesn't work in secure world

by Edward Yang

Hi experts, We are running Arm TF-M on stm32l562e_dk board, and we add a new secure partition based on TF-M architecture according to our specific application.In this new secure partition ,spi peripheral is used to communicate with a external spi nor flash. If we just test the spi driver in non-secure world(without tf-m),it works well. Then we put this driver in secure world,it's a plarform driver used by this new secure partition,and we have configured the spi peripheral as secure peripheral in gtzc_init_cfg() inside tfm_core_init(). We used a logic analyzer to debug, and found there was no spi communication waveform, it seems that this peripheral doesn't work in secure world,. We didn't declare this new partition's dependency on spi peripheral in its manifest files with mmio_regions. And I am not sure whether this is why the spi peripheral doesn't work. Is there anything else that we should pay attention to? 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, 3 months

1
0
0 0

Re: [TF-M] Failure building Musca B1 SE with armclang on Linux

by Raef Coles

What version of cmake are you using Chris? I notice it's installed via PIP, so it might be a particularly new one which has some incompatibility Raef ________________________________________ 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: 27 July 2021 16:58 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Failure building Musca B1 SE with armclang on Linux This is definitely something wrong with my system. I can’t build other targets with that toolchain either. Chris From: David Hu <David.Hu(a)arm.com> Sent: Tuesday, July 27, 2021 2:02 AM To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org; Brand Chris (CSCA CSS ICW SW PSW 1) <Chris.Brand(a)infineon.com> Cc: nd <nd(a)arm.com> Subject: RE: Failure building Musca B1 SE with armclang on Linux Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Chris, Xinyu helps run a Musca-B1 build on staging CI with Armclang 6.13 and the build succeeds. Please check the build log: https://ci.staging.trustedfirmware.org/view/TF-M/job/tf-m-build-config/2681… Best regards, Hu Ziji 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: Tuesday, July 27, 2021 3:32 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: Re: [TF-M] Failure building Musca B1 SE with armclang on Linux Hi Chris, Your command works well also on Windows, Clang v6.16.1, although had to modify -G”Unix Makefiles”. Hope it helps, 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: Tuesday, July 27, 2021 12:59 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>; Raef Coles <Raef.Coles(a)arm.com<mailto:Raef.Coles@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Failure building Musca B1 SE with armclang on Linux Hi Chris, Sorry for the trouble. I tried your build command and it worked with Armclang 6.14 on my ubuntu desktop. It looks like CMAKE_C_COMPILER_ID doesn’t receive the correct toolchain ID. Probably @Raef can help? Best regards, Hu Ziji ________________________________ 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: Tuesday, July 27, 2021 3:08 AM 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] Failure building Musca B1 SE with armclang on Linux My build command is this: cmake -S . -B build_musca_se_ARMCLANG_Debug '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/secure_enclave -DTFM_TOOLCHAIN_FILE=toolchain_ARMCLANG.cmake -DCMAKE_BUILD_TYPE=Debug -DTFM_ISOLATION_LEVEL=2 -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON -DTFM_PROFILE=profile_medium The tree I’m building is hash 76939d7ca9cea03b07d3617fbbdca09947d5cdf9, and the toolchain is version 6.13. I see the same error with version 6.12. The error message I get is this: [100%] Built target tfm_test_repo-populate gmake[1]: Leaving directory '/lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild' /lhome/cbrand/.local/lib/python3.6/site-packages/cmake/data/bin/cmake -E cmake_progress_start /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild/CMakeFiles 0 CMake Error at lib/ext/CMSIS_5/CMakeLists.txt:25 (message): does not have CMSIS RTX static libraries set up -- Configuring incomplete, errors occurred! I wonder whether it might be a toolchain configuration issue, but I’m pretty sure that I’ve built with this same toolchain on this same machine in the past… Gcc build with the same source and options works fine. 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, 3 months

2
1
0 0

Re: [TF-M] Failure building Musca B1 SE with armclang on Linux

by David Hu

Hi Chris, Xinyu helps run a Musca-B1 build on staging CI with Armclang 6.13 and the build succeeds. Please check the build log: https://ci.staging.trustedfirmware.org/view/TF-M/job/tf-m-build-config/2681… Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, July 27, 2021 3:32 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Failure building Musca B1 SE with armclang on Linux Hi Chris, Your command works well also on Windows, Clang v6.16.1, although had to modify -G"Unix Makefiles". Hope it helps, 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: Tuesday, July 27, 2021 12:59 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>; Raef Coles <Raef.Coles(a)arm.com<mailto:Raef.Coles@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Failure building Musca B1 SE with armclang on Linux Hi Chris, Sorry for the trouble. I tried your build command and it worked with Armclang 6.14 on my ubuntu desktop. It looks like CMAKE_C_COMPILER_ID doesn't receive the correct toolchain ID. Probably @Raef can help? Best regards, Hu Ziji ________________________________ 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: Tuesday, July 27, 2021 3:08 AM 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] Failure building Musca B1 SE with armclang on Linux My build command is this: cmake -S . -B build_musca_se_ARMCLANG_Debug '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/secure_enclave -DTFM_TOOLCHAIN_FILE=toolchain_ARMCLANG.cmake -DCMAKE_BUILD_TYPE=Debug -DTFM_ISOLATION_LEVEL=2 -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON -DTFM_PROFILE=profile_medium The tree I'm building is hash 76939d7ca9cea03b07d3617fbbdca09947d5cdf9, and the toolchain is version 6.13. I see the same error with version 6.12. The error message I get is this: [100%] Built target tfm_test_repo-populate gmake[1]: Leaving directory '/lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild' /lhome/cbrand/.local/lib/python3.6/site-packages/cmake/data/bin/cmake -E cmake_progress_start /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild/CMakeFiles 0 CMake Error at lib/ext/CMSIS_5/CMakeLists.txt:25 (message): does not have CMSIS RTX static libraries set up -- Configuring incomplete, errors occurred! I wonder whether it might be a toolchain configuration issue, but I'm pretty sure that I've built with this same toolchain on this same machine in the past... Gcc build with the same source and options works fine. 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, 3 months

2
1
0 0

Re: [TF-M] TF-M v1.4.0 release started

by Chris.Brand＠infineon.com

We ran the regression test suite on PSoC64. We did see some failures in the PSA Arch crypto tests: TEST: 226 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_sign_setup TEST: 227 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_update TEST: 228 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_sign_finish TEST: 229 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_verify_setup TEST: 230 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_verify_finish TEST: 262 | DESCRIPTION: Testing crypto hash functions APIs | UT: psa_hash_suspend TEST: 263 | DESCRIPTION: Testing crypto hash functions APIs | UT: psa_hash_resume This is consistent between Debug/Release and gcc/armclang. Do we know whether the PSA Arch Crypto tests are passing on other platforms? Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Monday, July 26, 2021 1:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M v1.4.0 release started Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi, All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag. The changes are minimal and shall not invalidate the tests, already done. Please use this tag for new tests and report any issues found by the end of July 30. Thanks and good luck, 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, July 21, 2021 11:25 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] TF-M v1.4.0 release started Hi, All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag. Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time. Please use this tag for your tests and report any issues found by the end of July 30. Thanks and good luck, Anton

4 years, 3 months

1
0
0 0

Re: [TF-M] TF-M v1.4.0 release started

by David Hu

Hi Jamie, Can I ask about your toolchain in use? GNUARM 10-2020-q4-major will cause a similar issue. TF-M suggests to avoid using this version: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/getti…. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, July 27, 2021 4:48 PM To: Jamie Mccrae <Jamie.Mccrae(a)lairdconnect.com>; Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] FW: TF-M v1.4.0 release started Hi Jamie, Sorry for the trouble. According to your description, the violation error is caused by non-secure test cases. is it correct? The error message is dumped by tfm_secure_api_error_handler(). It is called multiple times in Library model routine. Can you please help narrow the step in which tfm_secure_api_error_handler() is called? Besides, do you mind trying if IPC model can work on your board? Best regards, Hu Ziji 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: Tuesday, July 27, 2021 3:43 PM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] TF-M v1.4.0 release started Hi, I have tried the RC1 and RC2 on our platform, the BL5340 (nRF5340-based), which I am testing by building with the following: cmake -DTFM_PLATFORM=lairdconnectivity/bl5340_dvk_cpuapp -GNinja -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=on -DTEST_NS=on -DCMAKE_BUILD_TYPE=debug -DPS_TEST_NV_COUNTERS=on .. And upon starting the non-secure tests, a security violation occurs which reboots the module. Output from secure core: Test suite 'Crypto secure interface tests (TFM_S_CRYPTO_TEST_1XXX)' has PASSED Test suite 'Initial Attestation Service secure interface tests(TFM_S_ATTEST_TEST_1XXX)' has PASSED Test suite 'Platform Service Secure interface tests(TFM_S_PLATFORM_TEST_1XXX)' has PASSED Test suite 'Audit Logging secure interface test (TFM_S_AUDIT_TEST_1XXX)' has PASSED *** End of Secure test suites *** Security violation when calling secure API [INF] Starting bootloader [INF] Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3 [INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 [INF] Boot source: primary slot Output from non-secure core: Non-Secure system starting... #### Execute test suites for the Non-secure area #### Running Test Suite PSA protected storage NS interface tests (TFM_NS_PS_TEST_1XXX)... > Executing 'TFM_NS_PS_TEST_1001' Description: 'Set interface' Non-Secure system starting... So something that has changed from 1.3 to 1.4 seems to have broken our platform. Thanks, Jamie 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: 26 July 2021 09:50 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] TF-M v1.4.0 release started EXTERNAL EMAIL: Be careful with attachments and links. Hi, All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag. The changes are minimal and shall not invalidate the tests, already done. Please use this tag for new tests and report any issues found by the end of July 30. Thanks and good luck, 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, July 21, 2021 11:25 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] TF-M v1.4.0 release started Hi, All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag. Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time. Please use this tag for your tests and report any issues found by the end of July 30. Thanks and good luck, Anton 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, 3 months

2
1
0 0

FW: TF-M v1.4.0 release started

by David Hu

Hi Jamie, Sorry for the trouble. According to your description, the violation error is caused by non-secure test cases. is it correct? The error message is dumped by tfm_secure_api_error_handler(). It is called multiple times in Library model routine. Can you please help narrow the step in which tfm_secure_api_error_handler() is called? Besides, do you mind trying if IPC model can work on your board? Best regards, Hu Ziji 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: Tuesday, July 27, 2021 3:43 PM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] TF-M v1.4.0 release started Hi, I have tried the RC1 and RC2 on our platform, the BL5340 (nRF5340-based), which I am testing by building with the following: cmake -DTFM_PLATFORM=lairdconnectivity/bl5340_dvk_cpuapp -GNinja -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=on -DTEST_NS=on -DCMAKE_BUILD_TYPE=debug -DPS_TEST_NV_COUNTERS=on .. And upon starting the non-secure tests, a security violation occurs which reboots the module. Output from secure core: Test suite 'Crypto secure interface tests (TFM_S_CRYPTO_TEST_1XXX)' has PASSED Test suite 'Initial Attestation Service secure interface tests(TFM_S_ATTEST_TEST_1XXX)' has PASSED Test suite 'Platform Service Secure interface tests(TFM_S_PLATFORM_TEST_1XXX)' has PASSED Test suite 'Audit Logging secure interface test (TFM_S_AUDIT_TEST_1XXX)' has PASSED *** End of Secure test suites *** Security violation when calling secure API [INF] Starting bootloader [INF] Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3 [INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 [INF] Boot source: primary slot Output from non-secure core: Non-Secure system starting... #### Execute test suites for the Non-secure area #### Running Test Suite PSA protected storage NS interface tests (TFM_NS_PS_TEST_1XXX)... > Executing 'TFM_NS_PS_TEST_1001' Description: 'Set interface' Non-Secure system starting... So something that has changed from 1.3 to 1.4 seems to have broken our platform. Thanks, Jamie 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: 26 July 2021 09:50 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] TF-M v1.4.0 release started EXTERNAL EMAIL: Be careful with attachments and links. Hi, All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag. The changes are minimal and shall not invalidate the tests, already done. Please use this tag for new tests and report any issues found by the end of July 30. Thanks and good luck, 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, July 21, 2021 11:25 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] TF-M v1.4.0 release started Hi, All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag. Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time. Please use this tag for your tests and report any issues found by the end of July 30. Thanks and good luck, Anton 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, 3 months

1
0
0 0

Re: [TF-M] TF-M v1.4.0 release started

by Jamie Mccrae

Hi, I have tried the RC1 and RC2 on our platform, the BL5340 (nRF5340-based), which I am testing by building with the following: cmake -DTFM_PLATFORM=lairdconnectivity/bl5340_dvk_cpuapp -GNinja -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=on -DTEST_NS=on -DCMAKE_BUILD_TYPE=debug -DPS_TEST_NV_COUNTERS=on .. And upon starting the non-secure tests, a security violation occurs which reboots the module. Output from secure core: Test suite 'Crypto secure interface tests (TFM_S_CRYPTO_TEST_1XXX)' has PASSED Test suite 'Initial Attestation Service secure interface tests(TFM_S_ATTEST_TEST_1XXX)' has PASSED Test suite 'Platform Service Secure interface tests(TFM_S_PLATFORM_TEST_1XXX)' has PASSED Test suite 'Audit Logging secure interface test (TFM_S_AUDIT_TEST_1XXX)' has PASSED *** End of Secure test suites *** Security violation when calling secure API [INF] Starting bootloader [INF] Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3 [INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 [INF] Boot source: primary slot Output from non-secure core: Non-Secure system starting... #### Execute test suites for the Non-secure area #### Running Test Suite PSA protected storage NS interface tests (TFM_NS_PS_TEST_1XXX)... > Executing 'TFM_NS_PS_TEST_1001' Description: 'Set interface' Non-Secure system starting... So something that has changed from 1.3 to 1.4 seems to have broken our platform. Thanks, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 26 July 2021 09:50 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M v1.4.0 release started EXTERNAL EMAIL: Be careful with attachments and links. Hi, All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag. The changes are minimal and shall not invalidate the tests, already done. Please use this tag for new tests and report any issues found by the end of July 30. Thanks and good luck, 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, July 21, 2021 11:25 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] TF-M v1.4.0 release started Hi, All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag. Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time. Please use this tag for your tests and report any issues found by the end of July 30. Thanks and good luck, Anton 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, 3 months

1
0
0 0

Re: [TF-M] Failure building Musca B1 SE with armclang on Linux

by Anton Komlev

Hi Chris, Your command works well also on Windows, Clang v6.16.1, although had to modify -G"Unix Makefiles". Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, July 27, 2021 12:59 AM To: tf-m(a)lists.trustedfirmware.org; Chris.Brand(a)infineon.com; Raef Coles <Raef.Coles(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Failure building Musca B1 SE with armclang on Linux Hi Chris, Sorry for the trouble. I tried your build command and it worked with Armclang 6.14 on my ubuntu desktop. It looks like CMAKE_C_COMPILER_ID doesn't receive the correct toolchain ID. Probably @Raef can help? Best regards, Hu Ziji ________________________________ 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: Tuesday, July 27, 2021 3:08 AM 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] Failure building Musca B1 SE with armclang on Linux My build command is this: cmake -S . -B build_musca_se_ARMCLANG_Debug '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/secure_enclave -DTFM_TOOLCHAIN_FILE=toolchain_ARMCLANG.cmake -DCMAKE_BUILD_TYPE=Debug -DTFM_ISOLATION_LEVEL=2 -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON -DTFM_PROFILE=profile_medium The tree I'm building is hash 76939d7ca9cea03b07d3617fbbdca09947d5cdf9, and the toolchain is version 6.13. I see the same error with version 6.12. The error message I get is this: [100%] Built target tfm_test_repo-populate gmake[1]: Leaving directory '/lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild' /lhome/cbrand/.local/lib/python3.6/site-packages/cmake/data/bin/cmake -E cmake_progress_start /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild/CMakeFiles 0 CMake Error at lib/ext/CMSIS_5/CMakeLists.txt:25 (message): does not have CMSIS RTX static libraries set up -- Configuring incomplete, errors occurred! I wonder whether it might be a toolchain configuration issue, but I'm pretty sure that I've built with this same toolchain on this same machine in the past... Gcc build with the same source and options works fine. 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, 3 months

1
0
0 0

Re: [TF-M] Failure building Musca B1 SE with armclang on Linux

by David Hu

Hi Chris, Sorry for the trouble. I tried your build command and it worked with Armclang 6.14 on my ubuntu desktop. It looks like CMAKE_C_COMPILER_ID doesn't receive the correct toolchain ID. Probably @Raef can help? Best regards, Hu Ziji ________________________________ 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: Tuesday, July 27, 2021 3:08 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Failure building Musca B1 SE with armclang on Linux My build command is this: cmake -S . -B build_musca_se_ARMCLANG_Debug '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/secure_enclave -DTFM_TOOLCHAIN_FILE=toolchain_ARMCLANG.cmake -DCMAKE_BUILD_TYPE=Debug -DTFM_ISOLATION_LEVEL=2 -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON -DTFM_PROFILE=profile_medium The tree I'm building is hash 76939d7ca9cea03b07d3617fbbdca09947d5cdf9, and the toolchain is version 6.13. I see the same error with version 6.12. The error message I get is this: [100%] Built target tfm_test_repo-populate gmake[1]: Leaving directory '/lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild' /lhome/cbrand/.local/lib/python3.6/site-packages/cmake/data/bin/cmake -E cmake_progress_start /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild/CMakeFiles 0 CMake Error at lib/ext/CMSIS_5/CMakeLists.txt:25 (message): does not have CMSIS RTX static libraries set up -- Configuring incomplete, errors occurred! I wonder whether it might be a toolchain configuration issue, but I'm pretty sure that I've built with this same toolchain on this same machine in the past... Gcc build with the same source and options works fine. 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, 3 months

1
0
0 0

Failure building Musca B1 SE with armclang on Linux

by Chris.Brand＠infineon.com

My build command is this: cmake -S . -B build_musca_se_ARMCLANG_Debug '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/secure_enclave -DTFM_TOOLCHAIN_FILE=toolchain_ARMCLANG.cmake -DCMAKE_BUILD_TYPE=Debug -DTFM_ISOLATION_LEVEL=2 -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON -DTFM_PROFILE=profile_medium The tree I'm building is hash 76939d7ca9cea03b07d3617fbbdca09947d5cdf9, and the toolchain is version 6.13. I see the same error with version 6.12. The error message I get is this: [100%] Built target tfm_test_repo-populate gmake[1]: Leaving directory '/lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild' /lhome/cbrand/.local/lib/python3.6/site-packages/cmake/data/bin/cmake -E cmake_progress_start /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_musca_se_ARMCLANG_Debug/lib/ext/tfm_test_repo-subbuild/CMakeFiles 0 CMake Error at lib/ext/CMSIS_5/CMakeLists.txt:25 (message): does not have CMSIS RTX static libraries set up -- Configuring incomplete, errors occurred! I wonder whether it might be a toolchain configuration issue, but I'm pretty sure that I've built with this same toolchain on this same machine in the past... Gcc build with the same source and options works fine. 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, 3 months

1
0
0 0

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

by Thomas Törnblom

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

4 years, 3 months

1
0
0 0

Re: [TF-M] TF-M v1.4.0 release started

by Anton Komlev

Hi, All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag. The changes are minimal and shall not invalidate the tests, already done. Please use this tag for new tests and report any issues found by the end of July 30. Thanks and good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, July 21, 2021 11:25 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M v1.4.0 release started Hi, All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag. Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time. Please use this tag for your tests and report any issues found by the end of July 30. Thanks and good luck, Anton

4 years, 3 months

1
0
0 0

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

by David Hu

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

4 years, 3 months

2
2
0 0

FreeRTOS/TF-M OTA Integration

by Shebu Varghese Kuriakose

HI All, Here is blog published last week covering the integration of FreeRTOS OTA agent and TF-M's PSA Firmware Update Service- https://www.freertos.org/2021/07/secure-ota-updates-for-cortex-m-devices-wi… The OTA PAL implementation is now available as a submodule in Amazon FreeRTOS repository - ota_pal_psa in https://github.com/aws/amazon-freertos/tree/main/libraries/abstractions Previous FreeRTOS and TF-M integrations include PKCS#11/PSA API shim layer - psa in https://github.com/aws/amazon-freertos/tree/main/libraries/abstractions/pkc… and FreeRTOS kernel integration https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/main/portable/ThirdParty/G… Thanks, Shebu

4 years, 3 months

1
0
0 0

Re: [TF-M] Technical Forum call - July 22

by Anton Komlev

Hi, The agenda for the forum: 1. TF-M Porting guide. New documentation<https://tf-m-user-guide.trustedfirmware.org/docs/integration_guide/porting_…> prepared By Robert Wakim. 2. AOB Thanks, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, July 14, 2021 6:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - July 22 Hi, The next Technical Forum is planned on Thursday, July 22 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, 3 months

1
0
0 0

TF-M v1.4.0 release started

by Anton Komlev

Hi, All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag. Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time. Please use this tag for your tests and report any issues found by the end of July 30. Thanks and good luck, Anton

4 years, 3 months

1
0
0 0

Updates to the documentation

by Anton Komlev

Hello, Some of you might notice TF-M documentation updates but let me bring your attention to: 1. New look and layout of Getting Started Guides: https://tf-m-user-guide.trustedfirmware.org/docs/getting_started/tfm_gettin… 2. Porting TF-M to a New Hardware: https://tf-m-user-guide.trustedfirmware.org/docs/integration_guide/porting_… 3. Clear documentation URLs Please enjoy, contribute and give a feedback. Anton

4 years, 3 months

1
0
0 0

Re: [TF-M] TF-M is trying to migrate to mbedtls 3.0

by Chris.Brand＠infineon.com

Hi Summer. Is the plan that this is part of the 1.4 release? Thanks, Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Summer Qin via TF-M Sent: Monday, July 19, 2021 3:40 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M is trying to migrate to mbedtls 3.0 Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi, TF-M is trying to migrate to mbedtls 3.0. Here<https://review.trustedfirmware.org/q/topic:%22mbedtls3.0%22+(status:open%20…> are the patches for mbedtls 3.0 upgrading. Some patches touch platforms changes, especially are the following three patches: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10628/6 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10685/5 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10760/1 If these patches influence your platform's work, please feel free to let us know. Best Regards, Summer

4 years, 3 months

2
1
0 0

TF-M is trying to migrate to mbedtls 3.0

by Summer Qin

Hi, TF-M is trying to migrate to mbedtls 3.0. Here<https://review.trustedfirmware.org/q/topic:%22mbedtls3.0%22+(status:open%20…> are the patches for mbedtls 3.0 upgrading. Some patches touch platforms changes, especially are the following three patches: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10628/6 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10685/5 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10760/1 If these patches influence your platform's work, please feel free to let us know. Best Regards, Summer

4 years, 3 months

1
0
0 0

Technical Forum call - July 22

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 22 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, 3 months

1
0
0 0

[CANCELLED]: Technical Forum call - July 8

by Anton Komlev

Hi, Having no topics proposed or requested and considering the release preparation busy time, let me cancel this slot. A reminder: TF-M v1.4.0 code freeze is planned on July 16 and the release is on July 30. Thanks, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Monday, July 5, 2021 2:15 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - July 8 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

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 Raef Coles

Hey Poppy Along with all the good advice from Kevin, I wanted to highlight a couple of things: * There is an example of this already being done in TF-M. The nv-seed code calls into ITS depite being in the platform layer. This code isn't widely enabled, but works fine. (see platform/ext/common/template/crypto_nv_seed.c) * One nuance is when you're calling into the SP. Under library mode, it's not possible to call into another secure partition from a secure partitions's init code. It's possible to do this under IPC mode however. This is likely to cause problems with your usecase, as it seems likely you'd want to load cryptographic keys into the crypto partition during init. On another note - we're currently looking into tidying up our OTP support and creating some sort of basic provisioning workflow (which would also replace the current CryptoCell-312 provisioning code). Our design seems to be similar to yours (Either storing the provisioned data in real OTP or internal flash depending on platform support). This is currently still in progress, but we hope to get patches on the trustedfirmware.org gerrit soon. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 08 July 2021 03:56 To: Edward Yang; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder? Hi Poppy, As you said, how to read the provisioned information varies from platforms. So I cannot comment on how is your approach. But I can give something from the Framework’s point of view. The Client APIs mainly target two kind of consumers, one is the NSPE, the other is Secure Partitions. In your scenario B, a Partition wants to call psa_its_get(this is not the PSA Client API, but a “service API” that implemented with the Client APIs) to get something, that’s totally OK. Remember to add your Partition to the “dependencies” of the ITS Partition’s manifest, otherwise you’ll get errors for permission issues. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Thursday, July 8, 2021 10:43 AM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder? Hi Anton and Kevin, "call secure services directly” here means calling by PSA client API in IPC mode. Here is the scenarios, For example, a new secure partition is added ,and this partition provides some secure services. One service needs get some pre-provisioned information,such as a key. This operation(get pre-provisioned information) may vary with platforms. [cid:image001.gif@01D773E7.56814130] [cid:image002.gif@01D773E7.56814130] Scenario A:Target1(A board without MCU embedded Flash ) , the pre-provisioned information were stored in OTP during provisioning, so this target reads pre-provisioned information from OTP during deployment period. Scenario B: Target1(A board with MCU embedded Flash ) , assume the pre-provisioned information were stored in MCU embedded Flash by calling psa_its_set() service during provisioning(I am not sure whether this kind of implementation is right ), so this target needs reading pre-provisioned information by calling psa_its_get() service during deployment period. I am wondering whether this design breaks the design rules of tf-m. Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Kevin Peng 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/07/07 11:10 Please respond to Kevin Peng <Kevin.Peng(a)arm.com<mailto:Kevin.Peng@arm.com>> 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>> cc nd <nd(a)arm.com<mailto:nd@arm.com>> Subject Re: [TF-M] Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder? Hi Poppy, By “call secure services directly” I guess you mean function call? That is forbidden. Secure services can be only called by PSA Client APIs (psa_connect/psa_call/psa_close) or Partition provided APIs (for example psa_ps_set). As Anton mentioned, platform folder actually provide HW level support to Secure Partitions and Framework (SPM). Could you provide more details of you use case of calling Secure Services from platform folder? Best Regards, Kevin 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: Tuesday, July 6, 2021 8:31 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: Re: [TF-M] Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder? 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<mailto:tf-m-bounces@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<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@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. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@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, 3 months

1
0
0 0

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

by Kevin Peng

Hi Poppy, As you said, how to read the provisioned information varies from platforms. So I cannot comment on how is your approach. But I can give something from the Framework's point of view. The Client APIs mainly target two kind of consumers, one is the NSPE, the other is Secure Partitions. In your scenario B, a Partition wants to call psa_its_get(this is not the PSA Client API, but a "service API" that implemented with the Client APIs) to get something, that's totally OK. Remember to add your Partition to the "dependencies" of the ITS Partition's manifest, otherwise you'll get errors for permission issues. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Thursday, July 8, 2021 10:43 AM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder? Hi Anton and Kevin, "call secure services directly" here means calling by PSA client API in IPC mode. Here is the scenarios, For example, a new secure partition is added ,and this partition provides some secure services. One service needs get some pre-provisioned information,such as a key. This operation(get pre-provisioned information) may vary with platforms. [cid:image001.gif@01D773E7.56814130] [cid:image002.gif@01D773E7.56814130] Scenario A:Target1(A board without MCU embedded Flash ) , the pre-provisioned information were stored in OTP during provisioning, so this target reads pre-provisioned information from OTP during deployment period. Scenario B: Target1(A board with MCU embedded Flash ) , assume the pre-provisioned information were stored in MCU embedded Flash by calling psa_its_set() service during provisioning(I am not sure whether this kind of implementation is right ), so this target needs reading pre-provisioned information by calling psa_its_get() service during deployment period. I am wondering whether this design breaks the design rules of tf-m. Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Kevin Peng 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/07/07 11:10 Please respond to Kevin Peng <Kevin.Peng(a)arm.com<mailto:Kevin.Peng@arm.com>> 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>> cc nd <nd(a)arm.com<mailto:nd@arm.com>> Subject Re: [TF-M] Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder? Hi Poppy, By "call secure services directly" I guess you mean function call? That is forbidden. Secure services can be only called by PSA Client APIs (psa_connect/psa_call/psa_close) or Partition provided APIs (for example psa_ps_set). As Anton mentioned, platform folder actually provide HW level support to Secure Partitions and Framework (SPM). Could you provide more details of you use case of calling Secure Services from platform folder? Best Regards, Kevin 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: Tuesday, July 6, 2021 8:31 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: Re: [TF-M] Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder? 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<mailto:tf-m-bounces@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<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@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. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@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, 4 months

1
0
0 0

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

by Edward Yang

Hi Anton and Kevin, "call secure services directly” here means calling by PSA client API in IPC mode. Here is the scenarios, For example, a new secure partition is added ,and this partition provides some secure services. One service needs get some pre-provisioned information,such as a key. This operation(get pre-provisioned information) may vary with platforms. Scenario A:Target1(A board without MCU embedded Flash ) , the pre-provisioned information were stored in OTP during provisioning, so this target reads pre-provisioned information from OTP during deployment period. Scenario B: Target1(A board with MCU embedded Flash ) , assume the pre-provisioned information were stored in MCU embedded Flash by calling psa_its_set() service during provisioning(I am not sure whether this kind of implementation is right ), so this target needs reading pre-provisioned information by calling psa_its_get() service during deployment period. I am wondering whether this design breaks the design rules of tf-m. Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2021/07/07 11:10 Please respond to Kevin Peng <Kevin.Peng(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] Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder? Hi Poppy, By “call secure services directly” I guess you mean function call? That is forbidden. Secure services can be only called by PSA Client APIs (psa_connect/psa_call/psa_close) or Partition provided APIs (for example psa_ps_set). As Anton mentioned, platform folder actually provide HW level support to Secure Partitions and Framework (SPM). Could you provide more details of you use case of calling Secure Services from platform folder? Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, July 6, 2021 8:31 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder? 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. =====================================================================-- 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, 4 months

1
0
0 0

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

by Kevin Peng

Hi Poppy, By "call secure services directly" I guess you mean function call? That is forbidden. Secure services can be only called by PSA Client APIs (psa_connect/psa_call/psa_close) or Partition provided APIs (for example psa_ps_set). As Anton mentioned, platform folder actually provide HW level support to Secure Partitions and Framework (SPM). Could you provide more details of you use case of calling Secure Services from platform folder? Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, July 6, 2021 8:31 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder? 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<mailto:tf-m-bounces@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<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Whether the codes in platform folder of tf-m project can be allowed to call secure services in secure_fw folder? Hi experts, The tf-m project includes secure_fw and paltform these two folders, I want to know whether the codes in platform folder are allowed to call secure services directly? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M