- TF-M - lists.trustedfirmware.org

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, October 15 at 6:00-07: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] Musca-B1 and new build system

by Tamas Ban

Hi Raymond, Could you test this fix, it worked for me: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6274 BR, Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: 07 October 2020 09:26 To: Raymond Ngun <Raymond.Ngun(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Musca-B1 and new build system Hi Raymond, I propose the following way to debug: * I will build and send you a Musca-B1 image based on current master (fc8d2f7 Build: Remove PSA arch tests patch) for testing on your board. * Please send me both of your images, and if you have the corresponding *.axf files, and if you know the commit-id when they were built. * I would like to test and debug in my environment. * By the way do you have a debugger? Can you identify actually what does return an error during security counter init? BR, Tamas From: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Sent: 06 October 2020 23:53 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: Musca-B1 and new build system Hi Tamas, It didn't make a difference. I have an old muscb1 image around and that continues to work fine but the new images do not work. I wrote 2MB of 0xFF btw. Thanks, Ray From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>> Sent: Tuesday, October 6, 2020 8:40 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.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: Musca-B1 and new build system Hi Raymond, The build command and the hex creation are correct. Could you try to erase the entire eFlash before programming it? It can be done with Keil MDK, or you can create a hex file with srec_cat which only contains 0xFF bytes and program that one to the board. Let me know whether does it solved the issue. Tamas From: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Sent: 05 October 2020 23:07 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: Musca-B1 and new build system Thanks Tamas. Unfortunately, this did not work for me. Here is what I did to build. Let me know if I did something wrong. cmake -DTFM_PLATFORM=musca_b1 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_NS=ON -DTEST_S=ON ../ cmake --build . --target install srec_cat install/outputs/MUSCA_B1/bl2.bin -Binary -offset 0xA000000 install/outputs/MUSCA_B1/tfm_s_ns_signed.bin -Binary -offset 0xA020000 -o tfm.hex -Intel The resultant output is the following. Entering standby.. [INF] Starting bootloader [ERR] Error while initializing the security counter Thank you, Ray From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>> Sent: Thursday, October 1, 2020 3:05 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Musca-B1 and new build system Hi Raymond, Here is the proposed fix: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6028 Could you verify on your board? Pls use at build -DCMAKE_BUILD_TYPE=Debug for full logging in bootloader. Tamas 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: 01 October 2020 10:37 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.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] Musca-B1 and new build system Hi Raymond, Thanks for reporting the issue! The observed behaviour has two reason: - In the new build system the default CMAKE_BUILD_TYPE=Release. In this case the logging is disabled in MCUboot to get smaller binary. You can set manualy to Debug in the command line to enable logging from bootloader * This commit 7d591a684b4abb0f61fbba8668dd6ea7b4b68698 introduced a crash in Musca S1/B1. Fix is ongoing. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 30 September 2020 17:44 To: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Musca-B1 and new build system Hi all, I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions. 1. Is the latest tested with Musca-B1? 2. Can I obtain some updated information on how to build and create an image for Musca-B1? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 6 months

2
1
0 0

Re: [TF-M] New build system missing GNUARM_PREFIX support

by Gyorgy Szing

Hi, FIY this variable in the Linux world used to be called "CROSS_COMPILE" and both TF-A and OP-TEE is using the same convention. Would it be possible to align with this and rename the variable? For backwards compatibility it could be possible to use both for a while, and issue a warning when the with a deprecation message when the old one is sued. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 08 October 2020 11:03 To: tf-m(a)lists.trustedfirmware.org; Kumar Gala (kumar.gala(a)linaro.org) <kumar.gala(a)linaro.org> Subject: Re: [TF-M] New build system missing GNUARM_PREFIX support Hi, yes apologies that seems to have been lost. I was doing my best to track changes in the original cmake but it seems this one got missed. Can I ask - for the vendor triplet compilers (arm-etc-eabi-gcc), is it a compiler that the vendor is developing? In the new buildsystem, it might make sense to create a new compiler toolchain file that is almost identical to the GNU one, which would allow the two compilers to diverge slightly (in command-line options etc) if necessary. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 07 October 2020 17:26 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] New build system missing GNUARM_PREFIX support It looks like the GNUARM_PREFIX changes got dropped as part of the new build system. Can someone look at restoring those changes? - k -- 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

New build system missing GNUARM_PREFIX support

by Kumar Gala

It looks like the GNUARM_PREFIX changes got dropped as part of the new build system. Can someone look at restoring those changes? - k

4 years, 6 months

1
0
0 0

Re: [TF-M] Musca-B1 and new build system

by Tamas Ban

Hi Raymond, Here is the proposed fix: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6028 Could you verify on your board? Pls use at build -DCMAKE_BUILD_TYPE=Debug for full logging in bootloader. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: 01 October 2020 10:37 To: Raymond Ngun <Raymond.Ngun(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Musca-B1 and new build system Hi Raymond, Thanks for reporting the issue! The observed behaviour has two reason: - In the new build system the default CMAKE_BUILD_TYPE=Release. In this case the logging is disabled in MCUboot to get smaller binary. You can set manualy to Debug in the command line to enable logging from bootloader * This commit 7d591a684b4abb0f61fbba8668dd6ea7b4b68698 introduced a crash in Musca S1/B1. Fix is ongoing. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 30 September 2020 17:44 To: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Musca-B1 and new build system Hi all, I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions. 1. Is the latest tested with Musca-B1? 2. Can I obtain some updated information on how to build and create an image for Musca-B1? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 6 months

2
4
0 0

Re: [TF-M] -fshort-wchar

by Soby Mathew

Hi Øyvind Yes, you are right, we don't use wchar_t within TF-M and it does seem a trivial optimization without much benefit for TF-M other than introducing incompatibilities. Could you submit a patch to remove the same from GCC and ARMCLANG ? Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M Sent: 05 October 2020 09:12 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] -fshort-wchar Hi guys. I'm curious why -fshort-wchar is enabled for ARMCLANG and GNUARM (not IAR, interestingly). This should have little or no impact since wchar_t is so rarely used, and causes incompatibility when I try to link my Zephyr app with TF-M libs. Øyvind

4 years, 6 months

2
1
0 0

Re: [TF-M] Running Tests on Musca-A

by Tamas Ban

Hi Antonio, Could you try to do a debug build? By default the build type is release and in this case the MCUboot does not log anything. Set '-DCMAKE_BUILD_TYPE=Debug' in the command line when invoking the CMake generation phase. Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio Ken IANNILLO via TF-M Sent: 05 October 2020 16:13 To: Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Running Tests on Musca-A Thank you. However, it seems to flash without problem but after reset I don't get the expected output. The most I can get from the UART is the message "Musca A Firmware Version 3.0" when I power off and on, but none of the logging message expected from tf-m. Am I missing something? -- Antonio Ken Iannillo On 05/10/2020, 15:41, "Raef Coles" <Raef.Coles(a)arm.com> wrote: Apologies for the difficulties that you're having. We've recently done an upgrade to the buildsystem and some of the documentation hasn't been properly updated to reflect the new files. There is a patch in review to rectify this. For now, updated (plaintext) documentation can be found at https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/…. It should also be updated on the website sometime this week. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 05 October 2020 14:06 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Running Tests on Musca-A Dear all, I’m a researcher exploring TF-M. I have a Musca-A board, and I was able to build it with tests. Now, it seems that the examples running the tests [1] are outdated: I simply do not have the same files. My understanding is that I should merge two files (secure and non-secure) but it is not clear which ones and how the offset are computed. Can somebody help me on this? The output files in the /bin folder are: bl2, tfm_ns, and tfm_s in .axf, .bin, .elf, .hex, .map; tfm_s_ns.bin; and tfm_s_ns_signed.bin. Best, [1] https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… -- Antonio Ken Iannillo, PhD Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 | antonioken.iannillo(a)uni.lu<mailto:antonioken.iannillo@uni.lu> Join the conversation News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/> www.uni.lu/snt<http://www.uni.lu/snt> https://akiannillo.github.io/ P Please consider the environment before printing this e-mail

4 years, 6 months

2
1
0 0

Re: [TF-M] Running Tests on Musca-A

by Raef Coles

Apologies for the difficulties that you're having. We've recently done an upgrade to the buildsystem and some of the documentation hasn't been properly updated to reflect the new files. There is a patch in review to rectify this. For now, updated (plaintext) documentation can be found at https://review.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m/…. It should also be updated on the website sometime this week. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 05 October 2020 14:06 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Running Tests on Musca-A Dear all, I’m a researcher exploring TF-M. I have a Musca-A board, and I was able to build it with tests. Now, it seems that the examples running the tests [1] are outdated: I simply do not have the same files. My understanding is that I should merge two files (secure and non-secure) but it is not clear which ones and how the offset are computed. Can somebody help me on this? The output files in the /bin folder are: bl2, tfm_ns, and tfm_s in .axf, .bin, .elf, .hex, .map; tfm_s_ns.bin; and tfm_s_ns_signed.bin. Best, [1] https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… -- Antonio Ken Iannillo, PhD Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 | antonioken.iannillo(a)uni.lu<mailto:antonioken.iannillo@uni.lu> Join the conversation News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/> www.uni.lu/snt<http://www.uni.lu/snt> https://akiannillo.github.io/ P Please consider the environment before printing this e-mail

4 years, 6 months

2
1
0 0

Re: [TF-M] Running Tests on Musca-A

by Minos Galanakis

Hi Antonio, And welcome to the TF-M community. To get a better understanding of your issue it I would like to ask from some further details, such as the HEAD of the TF-M which you are trying to build, as well as the HEAD of the test branche. There has been a large overhaul of several components on the TF-M project, including the build system, so it would be good to have a common point of reference / By examples, do you refer to the official user guide? https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… For Musca_A you only need the hex file to flash it, which is generated using the srec_cat command mentioned above which utilises the platform specific offsets and merges the signed secure and non-secure binaries with the bootloader. If you are facing any issues flashing the HEX file, make sure that you have an up-to date daplink firmware. https://community.arm.com/developer/tools-software/oss-platforms/w/docs/554… If your output folder contains the HEX file, you can try flashing it by dragging and dropping, and see if it runs the regression tests. Regards, Minos Galanakis ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio Ken IANNILLO via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 05 October 2020 14:06 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Running Tests on Musca-A Dear all, I’m a researcher exploring TF-M. I have a Musca-A board, and I was able to build it with tests. Now, it seems that the examples running the tests [1] are outdated: I simply do not have the same files. My understanding is that I should merge two files (secure and non-secure) but it is not clear which ones and how the offset are computed. Can somebody help me on this? The output files in the /bin folder are: bl2, tfm_ns, and tfm_s in .axf, .bin, .elf, .hex, .map; tfm_s_ns.bin; and tfm_s_ns_signed.bin. Best, [1] https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… -- Antonio Ken Iannillo, PhD Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 | antonioken.iannillo(a)uni.lu<mailto:antonioken.iannillo@uni.lu> Join the conversation News<https://wwwen.uni.lu/snt/news_events> | Twitter<https://twitter.com/SnT_uni_lu> | Linkedin<https://www.linkedin.com/school/snt-lu/> www.uni.lu/snt<http://www.uni.lu/snt> https://akiannillo.github.io/ P Please consider the environment before printing this e-mail

4 years, 6 months

1
0
0 0

Running Tests on Musca-A

by Antonio Ken IANNILLO

Dear all, I’m a researcher exploring TF-M. I have a Musca-A board, and I was able to build it with tests. Now, it seems that the examples running the tests [1] are outdated: I simply do not have the same files. My understanding is that I should merge two files (secure and non-secure) but it is not clear which ones and how the offset are computed. Can somebody help me on this? The output files in the /bin folder are: bl2, tfm_ns, and tfm_s in .axf, .bin, .elf, .hex, .map; tfm_s_ns.bin; and tfm_s_ns_signed.bin. Best, [1] https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-docs-nightly/lastSt… -- Antonio Ken Iannillo, PhD Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 | antonioken.iannillo(a)uni.lu Join the conversation News | Twitter | Linkedin www.uni.lu/snt https://akiannillo.github.io/ P Please consider the environment before printing this e-mail

4 years, 6 months

1
0
0 0

Re: [TF-M] CORE_TEST and the new build system

by Raef Coles

Patches are now up for review. for TF-M: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6095/1 for tf-m-tests: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/6097 Any comments / reviews would be appreciated Raef ________________________________________ 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: 01 October 2020 10:33 To: tf-m(a)lists.trustedfirmware.org; Christopher Brand Subject: Re: [TF-M] CORE_TEST and the new build system Yes, it seems like the core tests slipped through conversion. I've already had a report of this and got a patch together but it needs some thorough testing since it affects the linking order. I'll notify here once the patch is submitted for review. Should be this morning. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 30 September 2020 23:45 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] CORE_TEST and the new build system It seems that docs/reference/services/core_test_services_integration_guide.rst hasn’t been updated to reflect the new build system (it says to build using ConfigCoreTest.cmake). That config isn’t mentioned in docs/getting_started/tfm_build_instruction.rst. So how do I build the CORE_TEST stuff with the new build system (I’m particularly interested in the IRQ test). Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- 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

-fshort-wchar

by Rønningstad, Øyvind

Hi guys. I'm curious why -fshort-wchar is enabled for ARMCLANG and GNUARM (not IAR, interestingly). This should have little or no impact since wchar_t is so rarely used, and causes incompatibility when I try to link my Zephyr app with TF-M libs. Øyvind

4 years, 6 months

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Raef Coles

Would it be possible to know what commit hash of TF-M you are currently using Kevin? I had thought there was now some error handling in place for this but it's possible that it doesn't work as it should. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 03 October 2020 14:37 To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] Following the TF-M build example Hi, I assume you are building under windows, if that is true, add a -G"Unix Makefiles" in the command line would make it work as a quick fix, since cmake treat the default build system under windows as MSVC. We are trying to create a patch to enhance this part. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Kilzer via TF-M Sent: Saturday, October 3, 2020 8:28 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Following the TF-M build example I’m following the first build example in docs\getting_started\tfm_build_instruction.rst, for the mps2/an521. cmake -S . -B cmake_build -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake Building on Windows with gnu, it progresses pretty far then stops with the error shown below. Any suggestions? Kevin -- Configuring done CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: tfm_s_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:27 (target_add_scatter_file) CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: tfm_ns_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:40 (target_add_scatter_file) CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: bl2_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:63 (target_add_scatter_file) CMake Generate step failed. Build files cannot be regenerated correctly.

4 years, 6 months

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Ken Liu

Hi, I assume you are building under windows, if that is true, add a -G"Unix Makefiles" in the command line would make it work as a quick fix, since cmake treat the default build system under windows as MSVC. We are trying to create a patch to enhance this part. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Kilzer via TF-M Sent: Saturday, October 3, 2020 8:28 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Following the TF-M build example I'm following the first build example in docs\getting_started\tfm_build_instruction.rst, for the mps2/an521. cmake -S . -B cmake_build -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake Building on Windows with gnu, it progresses pretty far then stops with the error shown below. Any suggestions? Kevin -- Configuring done CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: tfm_s_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:27 (target_add_scatter_file) CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: tfm_ns_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:40 (target_add_scatter_file) CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: bl2_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:63 (target_add_scatter_file) CMake Generate step failed. Build files cannot be regenerated correctly.

4 years, 6 months

1
0
0 0

Following the TF-M build example

by Kevin.Kilzer＠microchip.com

I'm following the first build example in docs\getting_started\tfm_build_instruction.rst, for the mps2/an521. cmake -S . -B cmake_build -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake Building on Windows with gnu, it progresses pretty far then stops with the error shown below. Any suggestions? Kevin -- Configuring done CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: tfm_s_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:27 (target_add_scatter_file) CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: tfm_ns_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:40 (target_add_scatter_file) CMake Error at toolchain_GNUARM.cmake:114 (add_library): No SOURCES given to target: bl2_scatter Call Stack (most recent call first): platform/ext/target/mps2/an521/CMakeLists.txt:63 (target_add_scatter_file) CMake Generate step failed. Build files cannot be regenerated correctly.

4 years, 6 months

1
0
0 0

New TF-M Build doesn't track config changes

by Soby Mathew

Hi, With the new build system, TF-M downloads all dependant repositories to the BUILD folder as part of CMAKE configuration. CMake does provide `make clean` target to clean the build and rebuild but this doesn't track any config changes between the builds. Previously, the CMake workflow was to delete all contents in the BUILD folder before re-configuring for a new build but now this means the developer has to re-download all the dependant git repositories before the project can be build again. This can be a slow and cumbersome process for developers. Deleting the CMakecache.txt doesn't seem to solve the problem either. The most obvious solution is to move the cloned repositories outside the BUILD/ folder , so we can follow the previous workflow of deleting the BUILD folder before re-build. The sample test sequence to reproduce the problem is given below: /* Build secure regressions test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug; make install /* reconfigure and build PSA Crypto API test suite */ $ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_PSA_API=CRYPTO; make install Built binary is still for regression test suite. There are multiple suggestions to solve the problem, One is to move the clone repositories outside the BUILD/ folder, or introduce a build target like `make cleanall` which does the equivalent of rm -rf !(lib) within the BUILD folder (i.e the build target will remove all folders except the lib folder which has the cloned repositories). Please let us know of your suggestions on this. Best Regards Soby Mathew

4 years, 6 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call – October 1

by Anton Komlev

Hi All, The agenda for the forum today: 1. New build system features, tricks and known issues. See you, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 28 September 2020 11:39 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call – October 1 Hello, The next Technical Forum is planned on Thursday, October 1 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, 6 months

1
0
0 0

Re: [TF-M] CORE_TEST and the new build system

by Raef Coles

Yes, it seems like the core tests slipped through conversion. I've already had a report of this and got a patch together but it needs some thorough testing since it affects the linking order. I'll notify here once the patch is submitted for review. Should be this morning. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 30 September 2020 23:45 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] CORE_TEST and the new build system It seems that docs/reference/services/core_test_services_integration_guide.rst hasn’t been updated to reflect the new build system (it says to build using ConfigCoreTest.cmake). That config isn’t mentioned in docs/getting_started/tfm_build_instruction.rst. So how do I build the CORE_TEST stuff with the new build system (I’m particularly interested in the IRQ test). Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 6 months

1
0
0 0

Re: [TF-M] Musca-B1 and new build system

by Tamas Ban

Hi Raymond, Thanks for reporting the issue! The observed behaviour has two reason: - In the new build system the default CMAKE_BUILD_TYPE=Release. In this case the logging is disabled in MCUboot to get smaller binary. You can set manualy to Debug in the command line to enable logging from bootloader * This commit 7d591a684b4abb0f61fbba8668dd6ea7b4b68698 introduced a crash in Musca S1/B1. Fix is ongoing. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M Sent: 30 September 2020 17:44 To: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Musca-B1 and new build system Hi all, I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions. 1. Is the latest tested with Musca-B1? 2. Can I obtain some updated information on how to build and create an image for Musca-B1? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 6 months

1
0
0 0

CORE_TEST and the new build system

by Christopher Brand

It seems that docs/reference/services/core_test_services_integration_guide.rst hasn't been updated to reflect the new build system (it says to build using ConfigCoreTest.cmake). That config isn't mentioned in docs/getting_started/tfm_build_instruction.rst. So how do I build the CORE_TEST stuff with the new build system (I'm particularly interested in the IRQ test). Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

1
0
0 0

Musca-B1 and new build system

by Raymond Ngun

Hi all, I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions. 1. Is the latest tested with Musca-B1? 2. Can I obtain some updated information on how to build and create an image for Musca-B1? Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

1
0
0 0

Re: [TF-M] Removal of MCUboot fork from TF-M

by Adrian Shaw

This is excellent work and great news for both projects. Well done. Best, Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 30 September 2020 11:13 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Removal of MCUboot fork from TF-M Hi, In the last few quarter TF-M team have worked on actively to upstream the TF-M related features from the forked MCUboot repo to the original repository. This activity has been finished recently and as a result the MCUboot fork has been removed from TF-M repo. Currently TF-M exclusively relies on MCUboot project as a secure bootloader. From now on all new development will be directly contributed to the upstream repo. List of feature which were upstreamed: * HW rollback protection * HW key integration * Data exchange between MCUboot and runtime firmware * RAM_LOAD boot mode * DIRECT_XIP boot mode BR, Tamas Ban

4 years, 7 months

1
0
0 0

Removal of MCUboot fork from TF-M

by Tamas Ban

Hi, In the last few quarter TF-M team have worked on actively to upstream the TF-M related features from the forked MCUboot repo to the original repository. This activity has been finished recently and as a result the MCUboot fork has been removed from TF-M repo. Currently TF-M exclusively relies on MCUboot project as a secure bootloader. From now on all new development will be directly contributed to the upstream repo. List of feature which were upstreamed: * HW rollback protection * HW key integration * Data exchange between MCUboot and runtime firmware * RAM_LOAD boot mode * DIRECT_XIP boot mode BR, Tamas Ban

4 years, 7 months

1
0
0 0

Using TF-M through ymodem to download tfm_s_enc_sign.bin---------STM32L562

by 徐鹏

Hello Jaouen, I have a development issue when running TFM download process on the STM32L562.Print a error log"[ERR] Image in the secondary slot is not valid!" when download tfm_s_enc_sign.bin.ALL other 3 bin（tfm_s_sign.bin，tfm_ns_sign.bin，tfm_ns_enc_sign.bin） download success. I follow the document UM2671 chapter 11.4 Download a new firmware image. The project is en.stm32cubel5_v1-3-0.zip，file：Projects\STM32L562E-DK\Applications\TFM Steps to reproduce: 1.run Projects\STM32L562E-DK\Applications\TFM\TFM_SBSFU_Boot\MDK-ARM\regression.bat to init device 2.build TFM_SBSFU_Boot application，TFM_Appli secure application，TFM_Appli non-secure application，Build TFM_Loader application 3.run Projects\STM32L562E-DK\Applications\TFM\TFM_SBSFU_Boot\MDK-ARM\TFM_UPDATE.bat to programing into STM32L5 internal and external Flash memory 4.success to run into app 5.press user button (blue) during board reset, the user enters local loader menu. 6.use ymodem to download tfm_s_enc_sign.bin to secure image 7.reset and then print error log "[ERR] Image in the secondary slot is not valid!" Reason： 1.hash verify not pass because after decrypt， the image not same with origin image.log as below： ===================================================== [INF] verify counter 0 1000000 1000000 [INF] counter 0 : ok [INF] hash256 : 54, cc, 2c, 4c, 97, b5, 55, 68, [INF] hash256 buf : cd, 76, a3, a1, cb, 1, 4d, bc, [ERR] Image in the secondary slot is not valid! ====================================================== Does anyone know what I39m doing wrong? Thanks in advance!

4 years, 7 months

1
0
0 0

Re: [TF-M] [RFC] The code review guideline

by Ken Liu

Hi, I would merge this one as it has been put there review for a while, thanks all the reviewers. This would provide a basic shape while we are creating new features, also could be viewed better after rendered. There would be many points can be updated later, let’s try to use it and see how it works – Create issues at https://developer.trustedfirmware.org/ and assign to me if there are, reply here is also workable. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Tuesday, September 1, 2020 9:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] The code review guideline Hi, We are creating one document to describe the code review guidelines: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5372 The goal of this document is to introduce the source management level concepts to be followed while reviewing a code – which try to simplify the contribution (but burdens the reviewers? 😉). Difference to the `coding style`: * It focuses more on the source placement, interface definition and including, etc. As this document is keeping evolving in a period, the plan is we merge a simple version as start and adding more contents by new patches, so please give enough comments if you have, and don’t forget the concept: we want to make things rational and simple. Thanks. /Ken

4 years, 7 months

1
0
0 0

TF-M Technical Forum call – October 1

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, October 1 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, 7 months

1
0
0 0

Updated invitation: TF-M tech Forum @ Thu 15 Oct 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

This event has been changed. 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/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 15 Oct 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NWRmOTZydWZobWFnZ3RvM… Invitation from Google Calendar: https://www.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://www.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 organiser and be added to the guest list, 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, 7 months

1
0
0 0

Invitation: TF-M tech Forum @ Thu 15 Oct 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. 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/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 15 Oct 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- organiser * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NWRmOTZydWZobWFnZ3RvM… Invitation from Google Calendar: https://www.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://www.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 organiser and be added to the guest list, 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, 7 months

1
0
0 0

Cancelled event with note: TF-M Tech Forum @ Thu 15 Oct 2020 16:00 - 17:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "This will be rescheduled with the time corrected" 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/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 15 Oct 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Invitation from Google Calendar: https://www.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://www.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 organiser and be added to the guest list, 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, 7 months

1
0
0 0

Invitation: TF-M Tech forum @ Thu 1 Oct 2020 16:00 - 17:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. 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/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 1 Oct 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=N29mbm1qN2prOXBxMDhpd… Invitation from Google Calendar: https://www.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://www.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 organiser and be added to the guest list, 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, 7 months

1
0
0 0

Cancelled event with note: TF-M Tech Forum @ Thu 1 Oct 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "To be rescheduled with the time corrected" 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/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 1 Oct 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Invitation from Google Calendar: https://www.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://www.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 organiser and be added to the guest list, 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, 7 months

1
0
0 0

Re: [TF-M] X.509 Certificate Chain Support in TF-M

by Ronald Cron

Hi, I haven't dug into the details here but just wanted to point out that there is an x509 library in Mbed TLS. Thanks, Ronald. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TF-M Sent: 28 September 2020 11:42 To: Soby Mathew <Soby.Mathew(a)arm.com>; David Brown <david.brown(a)linaro.org>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] X.509 Certificate Chain Support in TF-M Adding TF-M mailing list, in case anyone is interested in the topic. -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: 24 September 2020 15:02 To: David Brown <david.brown(a)linaro.org> Cc: Abhishek Pandit <Abhishek.Pandit(a)arm.com>; Kevin Townsend <kevin.townsend(a)linaro.org>; Anton Komlev <Anton.Komlev(a)arm.com>; David Wang <David.Wang(a)arm.com>; Tamas Ban <Tamas.Ban(a)arm.com>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com>; Adrian Shaw <Adrian.Shaw(a)arm.com> Subject: RE: X.509 Certificate Chain Support in TF-M [+Adrian] Hi David > To me, what might make some sense would be to have some kind of > restrictions on what can be done with the private key stored on the > secure side. If all operations are done through an extended API, > those would be the only operations permissible, whereas a generic > private key storage could allow rogue non-secure code to make use of > signing of other things, including signing non-resident data (one > device using another for attestation. At least the risks and costs of this should be considered. Thanks for the clarification. This would mean that given the current PSA Crypto design, the only way to achieve this would be to implement a custom RoT service in SPE. Hence the NSPE cannot make use of the key for arbitrary signing operation. > My primary concern with this solution at this point, is that we > haven't consider securing the protocol necessary to associate a > certificate/key pair with a particular device. Maybe we should be looking into SDO? Yes, that does seem like a good candidate. From my reading, several aspects of provisioning seem to be outside TF-M realm. > Having roots of trust instead of public keys (or certs) for direct > signing keys would give OEMs and other parties involved in the > firmware upgrade process more flexibility. > I see, thanks. We use certificate chains when firmware images need from different vendors need to be deployed in different privilege levels or multiple boot stages are present in A-profile. The Platform boot guide document https://developer.arm.com/documentation/den0072/0101/ mentions this as well. Possibly this is an enhancement to MCUBoot (Boot loader for TF-M). After talking with Adrian, I think there is consensus that certificate chain is a useful feature to have. So from my point of view, if there is some collaborative effort to develop such a service as TF-M specific extension, I think it would be very useful to the community. Best Regards Soby Mathew > -----Original Message----- > From: David Brown <david.brown(a)linaro.org> > Sent: 23 September 2020 19:12 > To: Soby Mathew <Soby.Mathew(a)arm.com> > Cc: Abhishek Pandit <Abhishek.Pandit(a)arm.com>; Kevin Townsend > <kevin.townsend(a)linaro.org>; Anton Komlev <Anton.Komlev(a)arm.com>; > David Wang <David.Wang(a)arm.com>; Tamas Ban <Tamas.Ban(a)arm.com>; Shebu > Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com> > Subject: Re: X.509 Certificate Chain Support in TF-M > > On Wed, Sep 23, 2020 at 04:52:13PM +0000, Soby Mathew wrote: > > > I had a review and thanks for the excellent proposal, and it does > > make sense to me to add this support but some questions from my side: > > > > 1. Do you envisage the new CSR API and ability to store certificate blobs in > > secure world as an extension to PSA Attestation API ? > > 2. I know it is desirable to add this functionality to secure world, but to > > clear my mind, Is it possible to provide the same functionality from Non > > Secure side but making use of PSA crypto APIs ? For example the > > PSA > Crypto > > could export the public key and sign necessary data to create > > the CSR > from > > NS side. Similarly new keys can be imported to Crypto by NS > > world while > the > > certificate chains are maintained in NS world for non IAT services. I may > > have missed some key point. > > I agree that there is little reason to store the certificates > themselves on the secure side. If they were modified or tampered > with, there would no longer be a private key to make use of them. > > > My primary concern with this solution at this point, is that we > haven't consider securing the protocol necessary to associate a > certificate/key pair with a particular device. Maybe we should be looking into SDO? > > > 3. I understood how we can make use of certificate chains for > > attestation, > but > > it is less clear how this can be made use of while booting firmware images. > > Could you elaborate more ? > > Only in the sense of allowing a signed firmware image to have a > certificate chain with it. Having roots of trust instead of public > keys (or certs) for direct signing keys would give OEMs and other > parties involved in the firmware upgrade process more flexibility. > > David -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 7 months

1
0
0 0

Re: [TF-M] X.509 Certificate Chain Support in TF-M

by Abhishek Pandit

Adding TF-M mailing list, in case anyone is interested in the topic. -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: 24 September 2020 15:02 To: David Brown <david.brown(a)linaro.org> Cc: Abhishek Pandit <Abhishek.Pandit(a)arm.com>; Kevin Townsend <kevin.townsend(a)linaro.org>; Anton Komlev <Anton.Komlev(a)arm.com>; David Wang <David.Wang(a)arm.com>; Tamas Ban <Tamas.Ban(a)arm.com>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com>; Adrian Shaw <Adrian.Shaw(a)arm.com> Subject: RE: X.509 Certificate Chain Support in TF-M [+Adrian] Hi David > To me, what might make some sense would be to have some kind of > restrictions on what can be done with the private key stored on the > secure side. If all operations are done through an extended API, > those would be the only operations permissible, whereas a generic > private key storage could allow rogue non-secure code to make use of > signing of other things, including signing non-resident data (one > device using another for attestation. At least the risks and costs of this should be considered. Thanks for the clarification. This would mean that given the current PSA Crypto design, the only way to achieve this would be to implement a custom RoT service in SPE. Hence the NSPE cannot make use of the key for arbitrary signing operation. > My primary concern with this solution at this point, is that we > haven't consider securing the protocol necessary to associate a > certificate/key pair with a particular device. Maybe we should be looking into SDO? Yes, that does seem like a good candidate. From my reading, several aspects of provisioning seem to be outside TF-M realm. > Having roots of trust instead of public keys (or certs) for direct > signing keys would give OEMs and other parties involved in the > firmware upgrade process more flexibility. > I see, thanks. We use certificate chains when firmware images need from different vendors need to be deployed in different privilege levels or multiple boot stages are present in A-profile. The Platform boot guide document https://developer.arm.com/documentation/den0072/0101/ mentions this as well. Possibly this is an enhancement to MCUBoot (Boot loader for TF-M). After talking with Adrian, I think there is consensus that certificate chain is a useful feature to have. So from my point of view, if there is some collaborative effort to develop such a service as TF-M specific extension, I think it would be very useful to the community. Best Regards Soby Mathew > -----Original Message----- > From: David Brown <david.brown(a)linaro.org> > Sent: 23 September 2020 19:12 > To: Soby Mathew <Soby.Mathew(a)arm.com> > Cc: Abhishek Pandit <Abhishek.Pandit(a)arm.com>; Kevin Townsend > <kevin.townsend(a)linaro.org>; Anton Komlev <Anton.Komlev(a)arm.com>; > David Wang <David.Wang(a)arm.com>; Tamas Ban <Tamas.Ban(a)arm.com>; Shebu > Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com> > Subject: Re: X.509 Certificate Chain Support in TF-M > > On Wed, Sep 23, 2020 at 04:52:13PM +0000, Soby Mathew wrote: > > > I had a review and thanks for the excellent proposal, and it does > > make sense to me to add this support but some questions from my side: > > > > 1. Do you envisage the new CSR API and ability to store certificate blobs in > > secure world as an extension to PSA Attestation API ? > > 2. I know it is desirable to add this functionality to secure world, but to > > clear my mind, Is it possible to provide the same functionality from Non > > Secure side but making use of PSA crypto APIs ? For example the > > PSA > Crypto > > could export the public key and sign necessary data to create > > the CSR > from > > NS side. Similarly new keys can be imported to Crypto by NS > > world while > the > > certificate chains are maintained in NS world for non IAT services. I may > > have missed some key point. > > I agree that there is little reason to store the certificates > themselves on the secure side. If they were modified or tampered > with, there would no longer be a private key to make use of them. > > > My primary concern with this solution at this point, is that we > haven't consider securing the protocol necessary to associate a > certificate/key pair with a particular device. Maybe we should be looking into SDO? > > > 3. I understood how we can make use of certificate chains for > > attestation, > but > > it is less clear how this can be made use of while booting firmware images. > > Could you elaborate more ? > > Only in the sense of allowing a signed firmware image to have a > certificate chain with it. Having roots of trust instead of public > keys (or certs) for direct signing keys would give OEMs and other > parties involved in the firmware upgrade process more flexibility. > > David

4 years, 7 months

1
0
0 0

Cypress PSoC64 support update

by Andrei Narkevitch

Hi all, Just to let you know, some time ago Cypress has officially released the PSoC64 platform. With this, we are planning to stop supporting old PSoC64 development kits and move our focus on the new release boards. This is mainly because the old boards were programmed with an old firmware which is not compatible with the changes we do to the TFM code and it would be an unnecessary overhead to support both versions. Please let us know if it causes any issues. The new PSoC64 kit: https://www.cypress.com/documentation/development-kitsboards/psoc-64-standa… Thanks, Andrei Narkevitch Cypress Semiconductor Corp. An Infineon Technologies Company This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 1 Oct 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. 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/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 1 Oct 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=N250M2VrZnZtMnY0MjU3d… Invitation from Google Calendar: https://www.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://www.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 organiser and be added to the guest list, 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, 7 months

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 15 Oct 2020 16:00 - 17:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. 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/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 15 Oct 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * Don Harbin * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MjRoajVlNjRuczZqYWIwN… Invitation from Google Calendar: https://www.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://www.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 organiser and be added to the guest list, 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, 7 months

1
0
0 0

New buildsystem merged

by Raef Coles

Hi all The new buildsystem has now been merged to both the trusted-firmware-m and tf-m-tests repositories. There are a few known issues: * STM platforms run into issues with flash space when building under debug configuration. * nxp/lpcxpresso66s69 fails regression tests - this is being looked into as a priority. For building with the new buildsystem, there have been some changes to the command-line. An example invocation is shown below. ``` cd <TFM root dir> mkdir build && cd build cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake make ``` CMAKE_TOOLCHAIN_FILE and TFM_PLATFORM are the only required arguments. CMAKE_TOOLCHAIN_FILE is conceptually a replacement for COMPILER. It is a path to one of the three toolchain files in the TFM root dir. * <TFM root dir>/toolchain_GNUARM.cmake * <TFM root dir>/toolchain_ARMCLANG.cmake * <TFM root dir>/toolchain_IARARM.cmake TFM_PLATFORM is conceptually a replacement for TARGET_PLATFORM. Unlike TARGET_PLATFORM it takes as an argument the path between `platform/ext/target` and the target dir. For example: * -DTFM_PLATFORM=musca_s1 * -DTFM_PLATFORM=cypress/psoc64 * -DTFM_PLATFORM=nxp/lpcxpresso55s69 PROJ_CONFIG has now been removed. Instead configuration has been simplified using composable variables. Enable regression tests: -DTEST_NS=ON -DTEST_S=ON Enable IPC mode: -DTFM_PSA_API=ON Set isolation level: -DTFM_ISOLATION_LEVEL=2 So instead of ConfigRegressionIPC: -DTEST_NS=ON -DTEST_S=ON -DTFM_PSA_API=ON For integration with other projects, there is a new option: -DNS=[ON/OFF] If NS is set to OFF, TFM will build only the secure image (as bin tfm_s.axf) and the PSA api as a static library. This should make integration with other projects much simpler. Other miscellaneous improvements: * Full ninja support * Automatic dependency management * generation of axf, elf, hex and bin files for all outputs * Full support for partial rebuilding and parallel building * Modular support for crypto accelerators * better integration of multi-core support For full details of buildsystem variable changes, refer to `docs/getting_started/tfm_build_instructions.rst` and `config/config_default.cmake` Raef

4 years, 7 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

Thanks all for the inputs. May I collect answers for these questions: * Does the build system/IDE support sub-project for components and finally assemble them into one final image? The intention is to check the possibility to integrate TFM with sub-projects instead of a whole item. * Is there scenarios that dynamic sections being added into sct/ld, how do you deal with this? A reference link is also helpful. The intention: TF-M is actually a set of components, and the secure firmware part (secure boot is another image binary so not listed here) contains: 1. Libraries. 2. Partitions. 3. SPM. 4. Image assembling with all above components. The straight way is to generate ABC as *.a and assemble them together into a final image. Then go through each component, A and C can be configured in C domain, as what they needs maybe just some feature flags. B is a bit special but we still could provide specification defined .json and its compatible .yaml manifest and pre-generated C-based manifest with preprocessors. D is the hard part, as it needs special arrangement inside ld/sct, which make this discussion happen. Even the ‘include’ and ‘preprocessor’ are supported inside sct/ld, we still can not avoid the partitions including part, we can not do a foreach on the partition list which involve the preprocessor complexity into sct/ld. Looks like the templating can’t be avoided here. For platform specific requirements like: * Some platform won’t separate RODATA and CODE; * Some platform got non-continuous memory regions for special data; Put a platform dedicated sct/ld into the platform folder would help; but to mitigate the effort of platform, a common sct/ld needs to be abstracted. Thanks again for your great feedback. /Ken [History collapsed due to message size limitation]

4 years, 7 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Reed Hinkel

Hello Gyrogy: Your comment raises the question. Why is TF-M so complex and does it need to be the only answer? Either it needs to be simplified or respect must be paid to support in commercial tools as a first class citizen. Commercial tools are the path for large scale product developers. If they can’t engage TF-M with commercial tools or SiP tools then developers will face challenges to develop with it. It there are challenges they may even avoid using it in favor of simplified solutions much as they do today. Multiple target use cases will be using various components of TF-M (MbedTLS with and without hardware interfaces, Attestation, Audit Logs, etc.): 1. Arm v8M – Cortex-M33, M35, M55 2. Dual Core Systems – Multiple possible configs 3. Cortex v6M of v7M – M0, M0+, M3 & M4 4. TF-A 5. Other Cortex-R & Cortex-A implementations This reality argues for a more modular build packaging system that allows for it. All the best! Reed From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Gyorgy Szing via TF-M <tf-m(a)lists.trustedfirmware.org> Reply-To: Gyorgy Szing <Gyorgy.Szing(a)arm.com> Date: Wednesday, September 23, 2020 at 5:04 AM To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the “ecosystem” solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs. Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that: * How could we get information from manifest files to the build? * How could we generate signed binary packages for the boot-loader? * How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.) None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M. /George From: Andrej Butok <andrey.butok(a)nxp.com> Sent: 23 September 2020 09:33 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:45 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] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can’t be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 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] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don’t think situation would be much worse with any mentioned solution than it is today. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 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] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature – but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on “simple” values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. “Not sure if all these format support #include” The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What’s your opinion on this? Best regards, Shawn

4 years, 7 months

2
2
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Soby Mathew

Thanks Gyorgy for your inputs. I haven't checked out the details of all the pre-build processing, but it does seem complex to solve this in a portable way, but one suggestion from me is that perhaps the output from the pre-build processing should be a standard C header and from then on the standardized C pre-processing can be used for the rest of the configuration. For example, instead of the pre-build step generating producing the final linker script , it could instead generate a C header file which then can be consumed by the linker script. Here only the C header is generated and the linker script is untouched. This means that, if the IDEs can find a path to generate this C header file somehow (either via IDE configuration or different custom pre-build processing), then rest of the setup continues in a C standard way. Best regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 23 September 2020 11:04 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Andrej, TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the "ecosystem" solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs. Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that: * How could we get information from manifest files to the build? * How could we generate signed binary packages for the boot-loader? * How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.) None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M. /George From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: 23 September 2020 09:33 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:45 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] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can't be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 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] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 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] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

4 years, 7 months

2
1
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Gyorgy Szing

Hi Andrej, TF-M relies heavily on compile time configuration, and C is quiet limited on that. This means we cannot rely on the only standardized part of the "ecosystem" solely, and we have to use non-standard tools. I would love to have a portable automation solution supported by most IDEs. Yes, a lot of projects can go well with a single configuration header but unfortunately TF-M is more complex than that: * How could we get information from manifest files to the build? * How could we generate signed binary packages for the boot-loader? * How could we control memory map in sync with the hw configuration in source files? (The current pre-processing linker files approach is already non-standard.) None of these can be solved with IDEs in a portable way. I understand that adding IDE support for TF-M is challenging but the root cause is not how we implemented the build system, but how IDEs can handle the complexity needed by TF-M. /George From: Andrej Butok <andrey.butok(a)nxp.com> Sent: 23 September 2020 09:33 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:45 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] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can't be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 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] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 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] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

4 years, 7 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

Hi, Thanks for the input - this should be the goal we are approaching. I believe the updated build system has changed something, and I will raise an proposal based on that during October, let's discuss when the proposal is done. Before that, two more questions: * So if a user have to modify the file manually, will they work on the .sct directly, or the .sct.template? * Does your IDE support pre-build function? What kinds of command it could support? An IDE specific script or general shell commands or python? Thanks. /Ken From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Wednesday, September 23, 2020 3:33 PM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, So we are using one default/typical configuration. If any change in it, a user have to do changes manually which are not clear without deeper knowledge of the TFM project. But this is the issue of the TF-M chosen approach - fully rely on cmake preprocessing. The proposal is to use approach which is good for all worlds (cmake and IDEs) and which is used by all embedded MCU open-source projects like MbedTLS, FreeRTOS, lwIP, FNET and etc. Which is to have only one set of platform-independent files and the framework configuration from a user/project configuration file. It will work for both worlds, will solve all configuration issues we have, and will make TF-M easy to use and more popular. I am talking about this from very beginning. As no steps in right direction, we have a forked TF-M for our SDK. Thanks George for support ;) Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:45 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] Proposal to separate SCT/LD into each platform folder Hi Andrej, Sounds like your IDE is using the default .sct/.ld file, may I ask some a question that: * Is there a scenario that someone wants to add more partitions other than the default ones into your system, and how could they do that? I believe the existing .sct/.ld do not support extra partitions out of the default ones unless some manually modification is done. We need to support more components (partition is the direct example), so in this case, the sct/ld can't be avoided to be modified. Or do you think if we put a specific .sct/.ld under nxp folder would work if there is no other partitions are needed? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, September 23, 2020 8:46 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] Proposal to separate SCT/LD into each platform folder Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 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] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

4 years, 7 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Gyorgy Szing

Hi, Good point, this is an important factor. I think templating can be IDE compliant as long as the IDE does support pre-build step(s). The current build flow already contains steps requiring this and thus I don't think situation would be much worse with any mentioned solution than it is today. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 September 2020 08:33 To: Ken Liu <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 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] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

4 years, 7 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Andrej Butok

Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

4 years, 7 months

2
1
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html [2] https://jinja.palletsprojects.com/en/2.11.x/ [3] https://github.com/kblomqvist/yasha From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

4 years, 7 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Gyorgy Szing

Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html [2] https://jinja.palletsprojects.com/en/2.11.x/ [3] https://github.com/kblomqvist/yasha From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

4 years, 7 months

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

4 years, 7 months

1
0
0 0

Linaro Connect Sessions of Interest

by Don Harbin

Hi All, As Linaro Connect starts tomorrow, here are some pointers to sessions that will be of interest related to trustedfirmware.org. - *PSA Secure Partitions in OP-TEE* - Tuesday, September 22nd (1:25-1:50pm UTC) - Speaker: Miklos Balint - Slides available here <https://static.sched.com/hosted_files/lvc20/9a/LVC20-112_PSA_Secure_Partiti…> - *Trusted Firmware Project update* - Tuesday, Sept. 22nd (2:00-2:25pm UTC) - Spreaders: Matteo Carlini, Shebu Kuriakose - Slides available here <https://static.sched.com/hosted_files/lvc20/1e/LVC20-113-Trusted-Firmware-p…> - *Scalable Security Using Trusted Firmware-M Profiles* - Wednesday September 23rd (11.45am – 12.10pm UTC) - Speakers: Shebu Kuiakose, David Want - Slides available here <https://static.sched.com/hosted_files/lvc20/d0/ScalableSecurityUsingTrusted…> - *Enable UEFI Secure Boot using OP-TEE as Secure Partition* - Thursday September 24th (3.45-4.10pm UTC) - Speakers: Sahil Malhotra, Ilias Apalodimas - *Secure Partition Manager (SEL2 firmware) for Arm A-class devices* - Thursday September 24th (4.15-4.40pm UTC) - Speaker: Olivier Deprez - Slides are available here <https://static.sched.com/hosted_files/lvc20/09/LVC20-305-secure-partition-m…> Some general pointers to sessions of potential interest: - Security related topics can be viewed here - Boot architecture topics can be viewed here As a reminder, sign up for tomorrow's event is at Linaro Connect Registration <https://connect.linaro.org/> and is free, so feel free to forward this information on. :) The overall schedule is available at the same link as registration in case you may be interested in other sessions. Best regards, Don

4 years, 7 months

1
0
0 0

Re: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0)

by Soby Mathew

For the record, I have attached the full log of the PSA Arch Crypto test run on AN521. The SHA of respective repositories are the test run given below: TF-M - 8f895ab8 PSA Arch tests - ee3c463d tf-m-tests - 7789423 mbedtls - tag: mbedtls-2.23.0 There is an additional failure for test "psa_close_key with RSA 2048 keypair" compared to the summary report below. This is due to incorrect build flag propagation for changing the ITS_MAX_ASSET_SIZE. This will be corrected in the following days. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 21 August 2020 11:22 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0) Just an update to this, I have merged the patch which upgrades to the latest mbedTLS tag. The PSA Arch initial attestation test suite fails to build after this merge due to width change of `ecc_curve_t` type. The issue is reported here in PSA Arch test github project : https://github.com/ARM-software/psa-arch-tests/pull/232 The patch for changing the ITS_MAX_ASSET_SIZE is still outstanding and I hope to merge it after a week. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Soby Mathew via TF-M Sent: 11 August 2020 16:24 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0) Hi Everyone The following patch updates the crypto service in TF-M to use the latest mbedTLS tag v2.23.0. All reviews for the same will be much appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5252/1 With this update, additional PSA APIs psa_hash_compute() and psa_hash_compare() are now supported. There is also another patch for platforms to update the ITS_MAX_ASSET_SIZE when testing with PSA Crypto API compliance test as one of the tests require a larger size: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5253/1 . Could the platform owners review the same and let me know whether the size changes are OK ? With the above patches, the API compliance remains the same as v1.0 Beta 3 and the PSA Crypto compliance test suite gives the below results (as tested on AN521) : ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 42 TOTAL SIM ERROR : 0 TOTAL FAILED : 17 TOTAL SKIPPED : 2 ****************************************** Best Regards Soby Mathes

4 years, 7 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Summer Qin

Hi Anton, I'd like to briefly introduce the enhancement of the TF-M initialization flow, about 20 minutes. Regards, Summer ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Sherry Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, September 15, 2020 3:08 PM To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - September 17 Hi Anton, I would like to give a very brief introduction of the integration work of TF-M and FreeRTOS Kernel which has been merged into FreeRTOS. It will take about 10 minutes around. Regards, Sherry From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 7 months

2
1
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Sherry Zhang

Hi Anton, I would like to give a very brief introduction of the integration work of TF-M and FreeRTOS Kernel which has been merged into FreeRTOS. It will take about 10 minutes around. Regards, Sherry From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 7 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Kevin Peng

Anton, I'd like to give an update on the HAL APIs, around 10 minutes. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 7 months

1
0
0 0

Secure Enclave solution in TF-M

by Mark Horvath

Dear All, Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653 I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP: https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Limitations, missing features, notes: * No support for isolation level2 on SSE-200 * Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave * Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave * All IPC message forwarding is a blocking call * Only one message is put into the mailbox at a time * Musca-B1 related documentation is not complete yet * Generated files are not committed, manifest parser should be run before build. * The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now * Cmake changes are rudimentary, will be rebased to new cmake system. Any feedback very welcomed! Best regards, Márk Horváth Senior Software Engineer Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com> Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary www.arm.com<http://www.arm.com/>

4 years, 7 months

1
0
0 0

Re: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS

by Anton Komlev

Great news! Congratulations, Shery, David. You made it happen! Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang via TF-M Sent: 14 September 2020 04:47 To: tf-m(a)lists.trustedfirmware.org; Sherry Zhang <Sherry.Zhang2(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS Thanks Sherry for sharing this great news! Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Sherry Zhang via TF-M Sent: Monday, September 14, 2020 9:50 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] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS Hi all, The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms. Regards, Sherry Zhang

4 years, 7 months

1
0
0 0

Re: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS

by David Wang

Thanks Sherry for sharing this great news! Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Sherry Zhang via TF-M Sent: Monday, September 14, 2020 9:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS Hi all, The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms. Regards, Sherry Zhang

4 years, 7 months

1
0
0 0

Integration of TF-M and FreeRTOS Kernel has been merged into FreeRTOS

by Sherry Zhang

Hi all, The integration of TF-M and FreeRTOS Kernel has been merged into the official FreeRTOS Kernel repository<https://github.com/FreeRTOS/FreeRTOS-Kernel> master branch. You can follow this port<https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/master/portable/ThirdParty…> on Cortex-M33 platforms. Regards, Sherry Zhang

4 years, 7 months

1
0
0 0

Re: [TF-M] The GNUARM linker script change about psa_client objects and the integration method [NXP]

by Ken Liu

Hi Andrej, Thanks, if the different approach for project compilation has its own ld file then we can remove these 4 lines - going to create a patch for this. BR /Ken From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Friday, September 11, 2020 9:10 PM To: Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: The GNUARM linker script change about psa_client objects and the integration method [NXP] Hi Ken, Guess, these lines where upstream from NXP SDK, which is using a different approach for project compilation. Most probably they may be removed for the original TFM. Best regards, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Friday, September 11, 2020 3:04 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] The GNUARM linker script change about psa_client objects and the integration method [NXP] Hi, When I was trying to re-arrange the linker script I found below changes: *psa_client.*(.text*) /* NXP */ *psa_client.*(.rodata*) *psa_service.*(.text*) /* NXP */ *psa_service.*(.rodata*) *psa_lifecycle.*(.text*) /* NXP */ *psa_lifecycle.*(.rodata*) *tfm_log_raw.*(.text*) /* NXP */ I think at least the psa_client.o and psa_service.o are included into the libtfmsprt.a so these items looks duplicated. What is the purpose of this change? Would it fix build problem or runtime problem? Thanks. /Ken

4 years, 7 months

1
0
0 0

The GNUARM linker script change about psa_client objects and the integration method [NXP]

by Ken Liu

Hi, When I was trying to re-arrange the linker script I found below changes: *psa_client.*(.text*) /* NXP */ *psa_client.*(.rodata*) *psa_service.*(.text*) /* NXP */ *psa_service.*(.rodata*) *psa_lifecycle.*(.text*) /* NXP */ *psa_lifecycle.*(.rodata*) *tfm_log_raw.*(.text*) /* NXP */ I think at least the psa_client.o and psa_service.o are included into the libtfmsprt.a so these items looks duplicated. What is the purpose of this change? Would it fix build problem or runtime problem? Thanks. /Ken

4 years, 7 months

1
0
0 0

Test message - please ignore

by Bill Fletcher

.. -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

4 years, 7 months

1
0
0 0

Test message please ignore

by Bill Fletcher

. -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

4 years, 7 months

1
0
0 0

Skip GNUARM startup initialization

by Summer Qin

Hi, There is no forwarded define for '__START' in the current TF-M design, then the runtime init provided by toolchain is applied. This runtime init did something unnecessary as the data copying and ZI has been done already by the startup code, jumping to spm::main would be the next job as SPM would prepare runtime environment for subsequent partition execution and itself won't need other runtime operations besides the data moving. I have created a patch to jump to main under GNUARM: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5609 Change the code is because this would easy the code reading -- most of the users won't check a compiler flag given in the build system for forwarding '__START', so they will try to find the __start from the toolchain source. Currently, we can not avoid depending on ARMCLANG runtime init, so need double check (also IAR). Please provide your feedback, we are changing the platform startup code and need your confirmation to see if it is applicable. Best Regards, Summer

4 years, 7 months

1
0
0 0

TF-M Technical Forum call - September 17

by Anton Komlev

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

4 years, 7 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Raef Coles

Note that it's also still possible to use the "old style" cmake syntax: ``` mkdir build cd build cmake -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake .. make ``` Ninja is also supported as a generator by using ``` mkdir build cd build cmake -GNinja -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake .. ninja ``` This has been noted in the updated build documentation patch, which will be pushed to review.trustedfirmware.org as soon as possible (with other bugfixes, including both of the bugs encountered earlier in the email chain). Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 09 September 2020 08:58 To: 'tf-m(a)lists.trustedfirmware.org' Cc: nd Subject: Re: [TF-M] TF-M build system update heads-up Great to hear that that. BTW, instead of building all targets using “install” You can build a specific target separately by: cmake --build cmake_build --target <target> To list the targets available. use: cmake --build cmake_build --target help Cheers, Anton From: Christopher Brand <chris.brand(a)cypress.com> Sent: 08 September 2020 22:30 To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: TF-M build system update heads-up Thanks, Anton. That does work. The command I ran was definitely correct – I’ve tried switching back-and-forth between “-B” and “--build”, and they consistently fail and succeed, respectively. I’ve also seen my email client change “--” to “—“. I’m running cmake 3.18.2 on Ubuntu 18.04. Chris 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, September 8, 2020 1:13 PM To: 'tf-m(a)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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Could you try this: cmake --build cmake_build -- install Please note, when I copied your command the minus sign “-” was incorrect – probably a dash or hyphen sign. Need double check the doc. Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 08 September 2020 19:48 To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.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 build system update heads-up Hi, Sorry to hear that. When you manage to find out the culprit please drop an email to the list. I am really curious. /George From: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Sent: 08 September 2020 19:08 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@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 build system update heads-up Thanks, Gyorgy. I did indeed have the double dash (pretty sure I just copied and pasted from the doc). I guess my email client decided to “fix it in the mail message. Chris From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Saturday, September 5, 2020 5:42 AM To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.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 build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, You need two dashes before install. Options with a single dash are processed by cmake. Options after a double dash (--) are passed over to the build tool (in this case gnumake). (See the cmake documentation [1].) So: cmake -B cmake_build -- install is the correct command. [cid:image001.png@01D68687.0FBC1660] I attached an image above to work around potential readability issues of some font sets. I hope it gets trough. [1] https://cmake.org/cmake/help/v3.0/manual/cmake.1.html /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 05 September 2020 00:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up Thanks, Anton. I tried again today, and got further – the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build – install This error seems like something trivial: CMake Error: The source directory “…/trusted-firmware-m/install" does not exist. Chris 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: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to “MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn’t successful. Following docs/getting_started/tfm_build_instruction.rst (the “Example: building TF-M for AN521 platform using GCC:” section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn’t being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris 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: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)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: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today – we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

1
0
0 0

Re: [TF-M] PSA tests: NVMEM section

by David Hu

Hi Øyvind, IMOO, such a NVME area is psa-arch-tests dedicated requirement, instead of TF-M implementation or FF-M definitions. I'd suggest to ask for more details in https://github.com/ARM-software/psa-arch-tests/. FYI a patch from psa-arch-test to enable such a NVME area in TF-M: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3360 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M Sent: Wednesday, September 9, 2020 3:48 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA tests: NVMEM section According to psa-arch-tests[1] the tests need an NVMEM area to write its states to. "Non-volatile memory support to preserve test status over watchdog timer reset. Each byte of this region must be initialised to FF at power on reset." I could not find any code that does this in the TF-M or PSA repos. How do other platforms reserve and manage this 1k area. [1]: https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/docs/p…

4 years, 7 months

2
1
0 0

Re: [TF-M] TF-M build system update heads-up

by Christopher Brand

Thanks, Anton. That does work. The command I ran was definitely correct – I’ve tried switching back-and-forth between “-B” and “--build”, and they consistently fail and succeed, respectively. I’ve also seen my email client change “--” to “—“. I’m running cmake 3.18.2 on Ubuntu 18.04. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, September 8, 2020 1:13 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Could you try this: cmake --build cmake_build -- install Please note, when I copied your command the minus sign “-” was incorrect – probably a dash or hyphen sign. Need double check the doc. Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 08 September 2020 19:48 To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.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 build system update heads-up Hi, Sorry to hear that. When you manage to find out the culprit please drop an email to the list. I am really curious. /George From: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Sent: 08 September 2020 19:08 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@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 build system update heads-up Thanks, Gyorgy. I did indeed have the double dash (pretty sure I just copied and pasted from the doc). I guess my email client decided to “fix it in the mail message. Chris From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Saturday, September 5, 2020 5:42 AM To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.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 build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, You need two dashes before install. Options with a single dash are processed by cmake. Options after a double dash (--) are passed over to the build tool (in this case gnumake). (See the cmake documentation [1].) So: cmake -B cmake_build -- install is the correct command. [cid:image001.png@01D685EC.35B811C0] I attached an image above to work around potential readability issues of some font sets. I hope it gets trough. [1] https://cmake.org/cmake/help/v3.0/manual/cmake.1.html /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 05 September 2020 00:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up Thanks, Anton. I tried again today, and got further – the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build – install This error seems like something trivial: CMake Error: The source directory “…/trusted-firmware-m/install" does not exist. Chris 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: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to “MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn’t successful. Following docs/getting_started/tfm_build_instruction.rst (the “Example: building TF-M for AN521 platform using GCC:” section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn’t being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris 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: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)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: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today – we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

2
1
0 0

PSA tests: NVMEM section

by Rønningstad, Øyvind

According to psa-arch-tests[1] the tests need an NVMEM area to write its states to. "Non-volatile memory support to preserve test status over watchdog timer reset. Each byte of this region must be initialised to FF at power on reset." I could not find any code that does this in the TF-M or PSA repos. How do other platforms reserve and manage this 1k area. [1]: https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/docs/p…

4 years, 7 months

1
0
0 0

Feature branch 'feature-isolation-level3' is created for related patches merging

by Ken Liu

Hi, A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging. The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please: IMPORTANT: Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'. BR /Ken

4 years, 7 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Anton Komlev

Hi Chris, Could you try this: cmake --build cmake_build -- install Please note, when I copied your command the minus sign “-” was incorrect – probably a dash or hyphen sign. Need double check the doc. Hope it helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 08 September 2020 19:48 To: Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M build system update heads-up Hi, Sorry to hear that. When you manage to find out the culprit please drop an email to the list. I am really curious. /George From: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Sent: 08 September 2020 19:08 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@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 build system update heads-up Thanks, Gyorgy. I did indeed have the double dash (pretty sure I just copied and pasted from the doc). I guess my email client decided to “fix it in the mail message. Chris From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Saturday, September 5, 2020 5:42 AM To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.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 build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, You need two dashes before install. Options with a single dash are processed by cmake. Options after a double dash (--) are passed over to the build tool (in this case gnumake). (See the cmake documentation [1].) So: cmake -B cmake_build -- install is the correct command. [cid:image001.png@01D68623.8624BBE0] I attached an image above to work around potential readability issues of some font sets. I hope it gets trough. [1] https://cmake.org/cmake/help/v3.0/manual/cmake.1.html /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 05 September 2020 00:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up Thanks, Anton. I tried again today, and got further – the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build – install This error seems like something trivial: CMake Error: The source directory “…/trusted-firmware-m/install" does not exist. Chris 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: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to “MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn’t successful. Following docs/getting_started/tfm_build_instruction.rst (the “Example: building TF-M for AN521 platform using GCC:” section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn’t being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris 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: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)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: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today – we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Gyorgy Szing

Hi Chris, You need two dashes before install. Options with a single dash are processed by cmake. Options after a double dash (--) are passed over to the build tool (in this case gnumake). (See the cmake documentation [1].) So: cmake -B cmake_build -- install is the correct command. [cid:image001.png@01D68392.B953F780] I attached an image above to work around potential readability issues of some font sets. I hope it gets trough. [1] https://cmake.org/cmake/help/v3.0/manual/cmake.1.html /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: 05 September 2020 00:26 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M build system update heads-up Thanks, Anton. I tried again today, and got further – the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build – install This error seems like something trivial: CMake Error: The source directory “…/trusted-firmware-m/install" does not exist. Chris 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: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)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] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to “MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn’t successful. Following docs/getting_started/tfm_build_instruction.rst (the “Example: building TF-M for AN521 platform using GCC:” section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn’t being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris 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: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)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: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today – we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

2
2
0 0

Re: [TF-M] TF-M build system update heads-up

by Christopher Brand

Thanks, Anton. I tried again today, and got further - the first cmake command seems to succeed, but the second failed. I used git fetch "https://review.trustedfirmware.org/TF-M/trusted-firmware-m" refs/changes/72/5472/1 && git checkout FETCH_HEAD to get the tree, followed by cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=debug and then cmake -B cmake_build - install This error seems like something trivial: CMake Error: The source directory ".../trusted-firmware-m/install" does not exist. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 11:35 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to "MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn't successful. Following docs/getting_started/tfm_build_instruction.rst (the "Example: building TF-M for AN521 platform using GCC:" section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn't being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris 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: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)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: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today - we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

1
0
0 0

Re: [TF-M] Changes to configure FPU at the architectural level in TF-M

by Robert Rostohar

Hi Soby, Hi Ken, Thanks for your replies. As mentioned before, majority of device vendors already provide system files (CMSIS standard) which configure also FPU. Take a look for example at the system file provided for STM32L5xx device family (part of STM32CubeL5 FW): https://github.com/STMicroelectronics/STM32CubeL5/blob/master/Drivers/CMSIS… Porting TF-M to a new device should be even simpler when such files can be used directly (or with as less modifications as possible). I'm not just looking at the few platforms that are directly supported within TF-M repo but rather how to reduce efforts to enable TF-M on any CMSIS-Core compliant device. Note: If current system files provided by vendors do not properly configure security features then this should be highlighted. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: Wednesday 2 September 2020 16:00 To: Ken Liu <Ken.Liu(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi Robert, The current architecture abstraction depends on the some CMSIS standard macros (like __FPU_USED) to be defined and if there are vendor tools which can generate the same system file, as long as they are using the standard macros, the architecture abstraction should work alright if the generated file can be included. As Ken says, this makes architecture initialization uniform across platforms and provides the right settings to be applied for security. It also reduces the platform porting effort for new platforms. Hence the move in such a direction. If we allow a mechanism to allow the platform provided system file to be used rather than the default system file, will that suffice your requirement ? Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 02 September 2020 11:11 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] Changes to configure FPU at the architectural level in TF-M Hi Robert, Thanks for the comment, just want to double check if the guidelines for vendors who providing platform sources to a secure software covers the recommendations here: https://lists.trustedfirmware.org/pipermail/tf-m/2020-June/001007.html As far as we can see not all existing platforms set the registers required in the above recommendation (In Jamie's second patch), so we are trying to provide an architecture-abstraction. Meanwhile, we would notify the platform owner checking the platform-specific setting. After all platform vendor confirmed the setting of FPU we can leave this back to platform setting as you suggested - but secure firmware core logic still needs to check if platform set the FPU setting correctly. @Soby @Jamie, please update if I missed something. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Robert Rostohar via TF-M Sent: Wednesday, September 2, 2020 5:30 PM To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@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] Changes to configure FPU at the architectural level in TF-M Hi Jamie, I have concerns with moving FPU configuration from platform to architecture-abstraction layer. FPU configuration is typically configured within system configuration files that are standardized in CMSIS and provided by device vendors. Some vendors provide also tools that auto-generate the system file based on user configuration (ex: STM32CubeMX). Therefore it would be better to leave the FPU configuration to the platform rather than moving it into architecture-abstraction. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Fox via TF-M Sent: Friday 28 August 2020 19:53 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] Changes to configure FPU at the architectural level in TF-M Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

4 years, 7 months

2
3
0 0

TF-M fault injection mitigation

by Tamas Ban

Hi, If you found yesterday the HW fault injection mitigation topic interesting and it raised your attention then you can find detailed info about it here: https://www.cl.cam.ac.uk/~rja14/Papers/whatyouc.pdf https://www.riscure.com/uploads/2018/11/201708_Riscure_Whitepaper_Side_Chan… The PRs to MCUBoot are here: https://github.com/JuulLabs-OSS/mcuboot/pull/776 https://github.com/JuulLabs-OSS/mcuboot/pull/789 Tamas

4 years, 7 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Anton Komlev

Hi Chris, Thanks for trying. Please specify the build type explicitly: -DCMAKE_BUILD_TYPE=debug It shall be defaulted to "MinSizeRel", but something went wrong. Will be fixed asap. Good luck, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: 03 September 2020 19:10 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M build system update heads-up I tried to build PSoC64 with the new build system a couple of days ago, and wasn't successful. Following docs/getting_started/tfm_build_instruction.rst (the "Example: building TF-M for AN521 platform using GCC:" section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn't being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris 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: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)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: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today - we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

1
0
0 0

Re: [TF-M] TF-M build system update heads-up

by Christopher Brand

I tried to build PSoC64 with the new build system a couple of days ago, and wasn't successful. Following docs/getting_started/tfm_build_instruction.rst (the "Example: building TF-M for AN521 platform using GCC:" section), I ran cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake That failed : CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:107 (if): if given arguments: "STREQUAL" "DEBUG" "OR" "STREQUAL" "Debug" "OR" "STREQUAL" "debug" Unknown arguments specified Looking at that file it seemed that the default for CMAKE_BUILD_TYPE wasn't being applied, so I tried this command: cmake -S . -B cmake_build -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel That got further, but failed with: CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:115 (target_include_directories): Cannot specify include directories for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:120 (target_compile_definitions): Cannot specify compile definitions for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:130 (target_sources): Cannot specify sources for target "mbedcrypto_crypto_service" which is not built by this project.CMake Error at secure_fw/partitions/crypto/CMakeLists.txt:135 (target_link_libraries): Cannot specify link libraries for target "mbedcrypto_crypto_service" which is not built by this project. At that point, I gave up. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, September 3, 2020 10:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M build system update heads-up CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, As I mentioned in the Open Tech Forum today - we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

1
0
0 0

TF-M build system update heads-up

by Anton Komlev

Hello, As I mentioned in the Open Tech Forum today - we are close to merge the new build system to the master branch. Plan to start doing that at the beginning of the next week. It might cause code freeze for several days and minor problems in corner cases after that. The intention is to clean it out before the next release in November. All changes to merge are in feature-ux-buildsystem branch at the moment. Please signal if it conflicts with your plans. Regards, Anton

4 years, 7 months

1
0
0 0

New build system with IAR

by Thomas Törnblom

I've started looking at the new build system, and it looks like a nice improvement. I have a problem, that likely has a simple solution, although I'm not sure which. I've looked at the AN521 target, and the preload.cmake file is included very early from the root CMakeLists.txt The first line of preload.cmake is: --- set(CMAKE_SYSTEM_PROCESSOR cortex-m33+nodsp) --- For IAR that line should be: --- set(CMAKE_SYSTEM_PROCESSOR Cortex-M33.no_dsp) --- I need to discriminate between the toolchains already there, but I haven't figured out what the best way would be to do that. Not much is setup at this moment in the run. Ideas? Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 7 months

1
1
0 0

Re: [TF-M] Simpler integration into other projects

by Anton Komlev

Hi Øyvind, Thank you for the proposal. Believe all agreed that NS side shall be separated from S side and be OS independent. There were multiple efforts recently toward this direction like repo split and build system refactoring. I think currently we almost achieve it. Assume you have seen that new build system allows creates S, NS, BL targets independently. Could you specify the remaining dependencies, you concern? Thanks, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Rønningstad, Øyvind via TF-M Sent: 02 September 2020 13:31 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Simpler integration into other projects Hi list I have a proposal to make it easier to integrate TF-M into other existing projects, e.g. RTOSes such as Zephyr. I'm using Zephyr as an example, but I mean that it should apply to any external project that wants to integrate TF-M. I'm assuming the project wants to use the secure FW as is, so no change is needed there. However, in the NS FW we want to integrate the NS callable (PSA) API into native Zephyr applications, but the NS ("app") part of TF-M has some OS dependencies that interfere with this. My proposal is that the TF-M build system creates OS-independent NS libs that can be linked directly into the native Zephyr app. Ideally, the Zephyr build system should need to only do the following: - Call TF-M build system. - Retrieve S binaries (and optionally mcuboot binary). - Link NS lib(s) into project app. - Add include directories to NS callable API. Additionally, the RTOS will likely need to make an OS wrapper to support the OS functions needed. Please tell me your thoughts. I'm not an expert in Cmake and libs, so please also tell me if the above is infeasible in any way. I think making such integrations as simple as possible will be very beneficial, not just when doing the initial integration, but continuously, since changes in TF-M will eventually require tweaks in the integration. Best regards, Øyvind Rønningstad -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 7 months

1
0
0 0

Re: [TF-M] CI Checkpatch

by Soby Mathew

Thanks Gyorgy for your inputs. My only concern with git hooks is that they are triggered when patches are pushed for review whereas checkpatch is something needs to be frequently run for non-trivial patchsets. The other issue is I am not sure whether we can pass different arguments to githooks whereas build system integration allows that (for example check the entire tree vs only the changed lines). Also having it part of regular build allows easier integration with work flow. Hence many OSS projects integrate this into regular build for this reason. But as you say, perhaps the first solution is to download the script and run locally and I don't have a strong opinion against git hooks either. Whatever works best can be used. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 02 September 2020 15:25 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] CI Checkpatch Hi, My two cents on the topic. Sort term Sort term it is possible to clone the ci-scripts repository and to run the check-patch script locally (https://git.trustedfirmware.org/ci/tf-m-ci-scripts.git/tree/run-checkpatch.…) . The script has some in-line documentation. Long term I think this is an automation topic which may have a connection to the build system, but the right place for a solution in not there. When it comes to automation the best is to differentiate two use cases: 1. Centralized. This is where the automation happens on a server, and the main purpose is to keep authentic records about quality, or to drive delivery (i.e. push documents to hosting provider.) For this we have Jenkins. 2. De-centralized. This is when the automation is executed on the developers machine. How the user interacts with this system can be an implementation detail. The same scripts could be executed by git hooks, manually, or by the build system. I think the best solution would be to use git-hooks for decentralized automation, as this is there already, and has a well defined and standard interface towards the developer. The main problem with git hooks is, git as a policy leaves hook management as the responsibility of the developer, and there is no built-in way to deploy hooks to the developers machine. (This is due to security considerations.) As a solution to this issue multiple "hook frameworks" have been developed. I suggest investigating these and to build a decentralize automation solution on top of one of them. Ideally the same scripts executed by Jenkins could be executed by the framework too. Some contenders (and the language thy are developed with): * https://github.com/icefox/git-hooks - bash * https://github.com/git-hooks/git-hooks -golang * https://github.com/gnustavo/Git-Hooks - perl Of course there are many more. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Soby Mathew via TF-M Sent: 02 September 2020 15:18 To: Karl Zhang <Karl.Zhang(a)arm.com<mailto:Karl.Zhang@arm.com>>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.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] CI Checkpatch Hi, Just my view on this, One of the things that will be helpful is to have is the checkpatch script imported into the project and have a `make checkpatch` build target. This will help to pipe clean check-patch errors from developer side before pushing patch for review. We could also make it a git hook but then I feel it is less convenient than having a regular build target. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Karl Zhang via TF-M Sent: 02 September 2020 01:56 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] CI Checkpatch Hi Chris, The CI job was trigged from https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3521, you could find a list of all jobs and status of each job on Gerrit page that triggered by that job, job list example can be found at the end of this email. Another way is from the link you mentioned, that is a pipeline of how CI jobs start from one stage to another stage, if you click on the node of each stage, "Triggered Builds" will list the related job and you can check the details of it. The Open CI for TF-M is under development of Linaro, development plan and status can be found from https://developer.trustedfirmware.org/w/collaboration/openci/ , it is not stable at this moment that we are continuously addressing on. There is no latest document for detail introduction of current Open CI yet. Open CI - developer.trustedfirmware.org<https://developer.trustedfirmware.org/w/collaboration/openci/> Milestone Deliverables Target Completion Status; M1: Planning, Handover and Deployment SOW and project plan Hand over from OCE to Developer Services developer.trustedfirmware.org For the checkpatch job, it is a part of the static check stage, the error from this stage won't impact the final CI score, we need more investigation before active all static checks. The CI jobs were not able to trigger manually. There is a request to Linaro for the requirement that already working on, hope it can be deployed to the public Open CI soon. Job list example on Gerrit after CI job: Passed: 4, Failed: 18, Not done: 0 AN519_GNUARM_ConfigRegressionIPCTfmLevel2_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29147/> -1 AN519_GNUARM_ConfigRegressionIPC_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29146/> -1 AN519_GNUARM_ConfigRegressionProfileS_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29152/> -1 AN519_GNUARM_ConfigRegression_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29144/> -1 .... checkpatch<http://ci.trustedfirmware.org/job/tf-m-checkpatch/472/> -1 cppcheck<http://ci.trustedfirmware.org/job/tf-m-cppcheck/472/> 1 lava_boot<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 lava_test<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 psoc64_GNUARM_ConfigRegressionIPCTfmLevel2_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29157/> -1 psoc64_GNUARM_ConfigRegressionIPC_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29154/> -1 tf-m-build<http://ci.trustedfirmware.org/job/tf-m-build-and-test/479/> -1 tf-m-build-docs<http://ci.trustedfirmware.org/job/tf-m-build-docs/647/> 1 Thanks, Karl Zhang ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, September 1, 2020 12:35 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] CI Checkpatch So I see the CI system runs checkpatch, but I don't see any mention of checkpatch under the "docs" directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - September 3

by Anton Komlev

Hello, The agenda for this forum: 1. Hardware fault injection mitigation 2. Secure Partition Addition Demonstration See you, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 26 August 2020 13:52 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 3 Hello, The next Technical Forum is planned on Thursday, September 3 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 Komlev

4 years, 7 months

1
0
0 0

Re: [TF-M] CI Checkpatch

by Gyorgy Szing

Hi, My two cents on the topic. Sort term Sort term it is possible to clone the ci-scripts repository and to run the check-patch script locally (https://git.trustedfirmware.org/ci/tf-m-ci-scripts.git/tree/run-checkpatch.…) . The script has some in-line documentation. Long term I think this is an automation topic which may have a connection to the build system, but the right place for a solution in not there. When it comes to automation the best is to differentiate two use cases: 1. Centralized. This is where the automation happens on a server, and the main purpose is to keep authentic records about quality, or to drive delivery (i.e. push documents to hosting provider.) For this we have Jenkins. 2. De-centralized. This is when the automation is executed on the developers machine. How the user interacts with this system can be an implementation detail. The same scripts could be executed by git hooks, manually, or by the build system. I think the best solution would be to use git-hooks for decentralized automation, as this is there already, and has a well defined and standard interface towards the developer. The main problem with git hooks is, git as a policy leaves hook management as the responsibility of the developer, and there is no built-in way to deploy hooks to the developers machine. (This is due to security considerations.) As a solution to this issue multiple "hook frameworks" have been developed. I suggest investigating these and to build a decentralize automation solution on top of one of them. Ideally the same scripts executed by Jenkins could be executed by the framework too. Some contenders (and the language thy are developed with): * https://github.com/icefox/git-hooks - bash * https://github.com/git-hooks/git-hooks -golang * https://github.com/gnustavo/Git-Hooks - perl Of course there are many more. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 02 September 2020 15:18 To: Karl Zhang <Karl.Zhang(a)arm.com>; Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] CI Checkpatch Hi, Just my view on this, One of the things that will be helpful is to have is the checkpatch script imported into the project and have a `make checkpatch` build target. This will help to pipe clean check-patch errors from developer side before pushing patch for review. We could also make it a git hook but then I feel it is less convenient than having a regular build target. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Karl Zhang via TF-M Sent: 02 September 2020 01:56 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] CI Checkpatch Hi Chris, The CI job was trigged from https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3521, you could find a list of all jobs and status of each job on Gerrit page that triggered by that job, job list example can be found at the end of this email. Another way is from the link you mentioned, that is a pipeline of how CI jobs start from one stage to another stage, if you click on the node of each stage, "Triggered Builds" will list the related job and you can check the details of it. The Open CI for TF-M is under development of Linaro, development plan and status can be found from https://developer.trustedfirmware.org/w/collaboration/openci/ , it is not stable at this moment that we are continuously addressing on. There is no latest document for detail introduction of current Open CI yet. Open CI - developer.trustedfirmware.org<https://developer.trustedfirmware.org/w/collaboration/openci/> Milestone Deliverables Target Completion Status; M1: Planning, Handover and Deployment SOW and project plan Hand over from OCE to Developer Services developer.trustedfirmware.org For the checkpatch job, it is a part of the static check stage, the error from this stage won't impact the final CI score, we need more investigation before active all static checks. The CI jobs were not able to trigger manually. There is a request to Linaro for the requirement that already working on, hope it can be deployed to the public Open CI soon. Job list example on Gerrit after CI job: Passed: 4, Failed: 18, Not done: 0 AN519_GNUARM_ConfigRegressionIPCTfmLevel2_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29147/> -1 AN519_GNUARM_ConfigRegressionIPC_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29146/> -1 AN519_GNUARM_ConfigRegressionProfileS_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29152/> -1 AN519_GNUARM_ConfigRegression_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29144/> -1 .... checkpatch<http://ci.trustedfirmware.org/job/tf-m-checkpatch/472/> -1 cppcheck<http://ci.trustedfirmware.org/job/tf-m-cppcheck/472/> 1 lava_boot<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 lava_test<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 psoc64_GNUARM_ConfigRegressionIPCTfmLevel2_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29157/> -1 psoc64_GNUARM_ConfigRegressionIPC_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29154/> -1 tf-m-build<http://ci.trustedfirmware.org/job/tf-m-build-and-test/479/> -1 tf-m-build-docs<http://ci.trustedfirmware.org/job/tf-m-build-docs/647/> 1 Thanks, Karl Zhang ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, September 1, 2020 12:35 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] CI Checkpatch So I see the CI system runs checkpatch, but I don't see any mention of checkpatch under the "docs" directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

1
0
0 0

Re: [TF-M] Changes to configure FPU at the architectural level in TF-M

by Soby Mathew

Hi Robert, The current architecture abstraction depends on the some CMSIS standard macros (like __FPU_USED) to be defined and if there are vendor tools which can generate the same system file, as long as they are using the standard macros, the architecture abstraction should work alright if the generated file can be included. As Ken says, this makes architecture initialization uniform across platforms and provides the right settings to be applied for security. It also reduces the platform porting effort for new platforms. Hence the move in such a direction. If we allow a mechanism to allow the platform provided system file to be used rather than the default system file, will that suffice your requirement ? Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 02 September 2020 11:11 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi Robert, Thanks for the comment, just want to double check if the guidelines for vendors who providing platform sources to a secure software covers the recommendations here: https://lists.trustedfirmware.org/pipermail/tf-m/2020-June/001007.html As far as we can see not all existing platforms set the registers required in the above recommendation (In Jamie's second patch), so we are trying to provide an architecture-abstraction. Meanwhile, we would notify the platform owner checking the platform-specific setting. After all platform vendor confirmed the setting of FPU we can leave this back to platform setting as you suggested - but secure firmware core logic still needs to check if platform set the FPU setting correctly. @Soby @Jamie, please update if I missed something. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Robert Rostohar via TF-M Sent: Wednesday, September 2, 2020 5:30 PM To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@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] Changes to configure FPU at the architectural level in TF-M Hi Jamie, I have concerns with moving FPU configuration from platform to architecture-abstraction layer. FPU configuration is typically configured within system configuration files that are standardized in CMSIS and provided by device vendors. Some vendors provide also tools that auto-generate the system file based on user configuration (ex: STM32CubeMX). Therefore it would be better to leave the FPU configuration to the platform rather than moving it into architecture-abstraction. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Fox via TF-M Sent: Friday 28 August 2020 19:53 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] Changes to configure FPU at the architectural level in TF-M Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

4 years, 7 months

1
0
0 0

Re: [TF-M] CI Checkpatch

by Soby Mathew

Hi, Just my view on this, One of the things that will be helpful is to have is the checkpatch script imported into the project and have a `make checkpatch` build target. This will help to pipe clean check-patch errors from developer side before pushing patch for review. We could also make it a git hook but then I feel it is less convenient than having a regular build target. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Karl Zhang via TF-M Sent: 02 September 2020 01:56 To: tf-m(a)lists.trustedfirmware.org; Christopher Brand <chris.brand(a)cypress.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] CI Checkpatch Hi Chris, The CI job was trigged from https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3521, you could find a list of all jobs and status of each job on Gerrit page that triggered by that job, job list example can be found at the end of this email. Another way is from the link you mentioned, that is a pipeline of how CI jobs start from one stage to another stage, if you click on the node of each stage, "Triggered Builds" will list the related job and you can check the details of it. The Open CI for TF-M is under development of Linaro, development plan and status can be found from https://developer.trustedfirmware.org/w/collaboration/openci/ , it is not stable at this moment that we are continuously addressing on. There is no latest document for detail introduction of current Open CI yet. Open CI - developer.trustedfirmware.org<https://developer.trustedfirmware.org/w/collaboration/openci/> Milestone Deliverables Target Completion Status; M1: Planning, Handover and Deployment SOW and project plan Hand over from OCE to Developer Services developer.trustedfirmware.org For the checkpatch job, it is a part of the static check stage, the error from this stage won't impact the final CI score, we need more investigation before active all static checks. The CI jobs were not able to trigger manually. There is a request to Linaro for the requirement that already working on, hope it can be deployed to the public Open CI soon. Job list example on Gerrit after CI job: Passed: 4, Failed: 18, Not done: 0 AN519_GNUARM_ConfigRegressionIPCTfmLevel2_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29147/> -1 AN519_GNUARM_ConfigRegressionIPC_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29146/> -1 AN519_GNUARM_ConfigRegressionProfileS_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29152/> -1 AN519_GNUARM_ConfigRegression_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29144/> -1 .... checkpatch<http://ci.trustedfirmware.org/job/tf-m-checkpatch/472/> -1 cppcheck<http://ci.trustedfirmware.org/job/tf-m-cppcheck/472/> 1 lava_boot<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 lava_test<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 psoc64_GNUARM_ConfigRegressionIPCTfmLevel2_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29157/> -1 psoc64_GNUARM_ConfigRegressionIPC_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29154/> -1 tf-m-build<http://ci.trustedfirmware.org/job/tf-m-build-and-test/479/> -1 tf-m-build-docs<http://ci.trustedfirmware.org/job/tf-m-build-docs/647/> 1 Thanks, Karl Zhang ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, September 1, 2020 12:35 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] CI Checkpatch So I see the CI system runs checkpatch, but I don't see any mention of checkpatch under the "docs" directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

1
0
0 0

Re: [TF-M] psa_key_id_t type mismatch --- HardFault

by David Hu

Hi Alamy, In my very own opinion, `psk_key_id_t` defined as structure seems to be Mbed Crypto/MbedTLS own definition and should be transparent to applications calling `psa_open_key()`, as described in https://github.com/ARMmbed/mbedtls/blob/v2.23.0/include/psa/crypto_platform…. TF-M provides standard PSA APIs and therefore the `psa_key_id_t` in `psa_open_key()` is `uint32_t` as defined in PSA Cryptography API v1 Beta 3. The `uint32_t` `psa_key_id_t` is defined in `interface/include/psa/crypto_types.h` and included by TF-M Crypto interface files. Then when TF-M Crypto service invokes Mbed Crypto/MbedTLS APIs to fulfill the `psa_open_key()`, it includes Mbed Crypto/MbedTLS specific header file, in which `psa_key_id_t` is defined as a structure to support multiple client. For example, `crypto_key.c` constructs a `psa_key_id_t` structure and pass it to Mbed Crypto/MbedTLS `psa_open_key()` implementation. (https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…) It requires @Jamie Fox<mailto:Jamie.Fox@arm.com> and @Soby Mathew<mailto:Soby.Mathew@arm.com> help to provide a comprehensive answer. 😉 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Alamy Liu via TF-M Sent: Tuesday, September 1, 2020 1:23 AM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] psa_key_id_t type mismatch --- HardFault Sorry all, this is a FALSE alarm. Although some codes still include the local header file (uint32_t), none of them use psa_key_id_t at all. Maybe the code should be more clean, but there is no run-time problem! Sorry if it causes problems, Alamy On Mon, Aug 31, 2020 at 8:38 AM Alamy Liu <alamy.liu(a)gmail.com<mailto:alamy.liu@gmail.com>> wrote: Dear all, While I was working on the PSoC64 platform, I hit the psa_key_id_t type mismatch problem. The patch - 98ab441e096f enables MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER Which in terms to use the psa_key_id_t structure (psa_key_file_id_t) in <mbed-crypto/mbedtls>/include/psa/crypto_platform.h Interestingly, psa_key_id_t is also defined in <tf-m>/interface/include/psa/crypto_types.h, as a uint32_t. So, I do the following testing I could compile the master HEAD no problem 66ee5c8861 (HEAD, origin/master, origin/HEAD) Tools: update iat-verifier README and samples I assume the psa_key_id_t should be a structure (from mbed-crypto/mbedtls), I applied the patch below --- a/interface/include/psa/crypto_types.h +++ b/interface/include/psa/crypto_types.h @@ -211,6 +211,8 @@ typedef uint8_t psa_key_persistence_t; */ typedef uint32_t psa_key_location_t; +#if !defined(MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER) +#error Should not compile this /** Encoding of identifiers of persistent keys. * * - Applications may freely choose key identifiers in the range @@ -222,6 +224,7 @@ typedef uint32_t psa_key_location_t; */ typedef uint32_t psa_key_id_t; #define PSA_KEY_ID_INIT 0 +#endif Then, I notice that there are still many files that use uint32_t psa_key_id_t in the TF-M source tree. a) It's good (lucky?) that TF-M seems to cut it cleanly so it doesn't run into problems (well, it happens on PSoC64, or I won't notice it). b) It's bad that psa_key_id_t in TF-M has two different types. I'm not going to argue what's correct/wrong. Maybe this kind of coding could be a feature in the future. I just go with it. But I found no information to define the boundary of the two types under the <tf-m>/docs/ directory. I would like to know where the boundary is, in TF-M. In other words, Which part of the code should use the structure definition from mbedtls/mbed-crypto; which part of the code should use uint32_t ? In my work, the problem happens when it passes psa_key_id_t as a parameter, the parent & child functions see it differently (HardFault, in my case, memory violation to other parameters). e.g.: func_a.c (structure), func_b.c (uint32_t). func_b.h ---- the type changes when it's included by func_a.c and/or func_b.c Regards, Alamy

4 years, 7 months

2
1
0 0

Simpler integration into other projects

by Rønningstad, Øyvind

Hi list I have a proposal to make it easier to integrate TF-M into other existing projects, e.g. RTOSes such as Zephyr. I'm using Zephyr as an example, but I mean that it should apply to any external project that wants to integrate TF-M. I'm assuming the project wants to use the secure FW as is, so no change is needed there. However, in the NS FW we want to integrate the NS callable (PSA) API into native Zephyr applications, but the NS ("app") part of TF-M has some OS dependencies that interfere with this. My proposal is that the TF-M build system creates OS-independent NS libs that can be linked directly into the native Zephyr app. Ideally, the Zephyr build system should need to only do the following: - Call TF-M build system. - Retrieve S binaries (and optionally mcuboot binary). - Link NS lib(s) into project app. - Add include directories to NS callable API. Additionally, the RTOS will likely need to make an OS wrapper to support the OS functions needed. Please tell me your thoughts. I'm not an expert in Cmake and libs, so please also tell me if the above is infeasible in any way. I think making such integrations as simple as possible will be very beneficial, not just when doing the initial integration, but continuously, since changes in TF-M will eventually require tweaks in the integration. Best regards, Øyvind Rønningstad

4 years, 7 months

1
0
0 0

Re: [TF-M] Changes to configure FPU at the architectural level in TF-M

by Ken Liu

Hi Robert, Thanks for the comment, just want to double check if the guidelines for vendors who providing platform sources to a secure software covers the recommendations here: https://lists.trustedfirmware.org/pipermail/tf-m/2020-June/001007.html As far as we can see not all existing platforms set the registers required in the above recommendation (In Jamie's second patch), so we are trying to provide an architecture-abstraction. Meanwhile, we would notify the platform owner checking the platform-specific setting. After all platform vendor confirmed the setting of FPU we can leave this back to platform setting as you suggested - but secure firmware core logic still needs to check if platform set the FPU setting correctly. @Soby @Jamie, please update if I missed something. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: Wednesday, September 2, 2020 5:30 PM To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi Jamie, I have concerns with moving FPU configuration from platform to architecture-abstraction layer. FPU configuration is typically configured within system configuration files that are standardized in CMSIS and provided by device vendors. Some vendors provide also tools that auto-generate the system file based on user configuration (ex: STM32CubeMX). Therefore it would be better to leave the FPU configuration to the platform rather than moving it into architecture-abstraction. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Fox via TF-M Sent: Friday 28 August 2020 19:53 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] Changes to configure FPU at the architectural level in TF-M Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

4 years, 7 months

1
0
0 0

Re: [TF-M] Changes to configure FPU at the architectural level in TF-M

by Robert Rostohar

Hi Jamie, I have concerns with moving FPU configuration from platform to architecture-abstraction layer. FPU configuration is typically configured within system configuration files that are standardized in CMSIS and provided by device vendors. Some vendors provide also tools that auto-generate the system file based on user configuration (ex: STM32CubeMX). Therefore it would be better to leave the FPU configuration to the platform rather than moving it into architecture-abstraction. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Fox via TF-M Sent: Friday 28 August 2020 19:53 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Changes to configure FPU at the architectural level in TF-M Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

4 years, 7 months

1
0
0 0

Re: [TF-M] CI Checkpatch

by Karl Zhang

Hi Chris, The CI job was trigged from https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/3521, you could find a list of all jobs and status of each job on Gerrit page that triggered by that job, job list example can be found at the end of this email. Another way is from the link you mentioned, that is a pipeline of how CI jobs start from one stage to another stage, if you click on the node of each stage, "Triggered Builds" will list the related job and you can check the details of it. The Open CI for TF-M is under development of Linaro, development plan and status can be found from https://developer.trustedfirmware.org/w/collaboration/openci/ , it is not stable at this moment that we are continuously addressing on. There is no latest document for detail introduction of current Open CI yet. Open CI - developer.trustedfirmware.org<https://developer.trustedfirmware.org/w/collaboration/openci/> Milestone Deliverables Target Completion Status; M1: Planning, Handover and Deployment SOW and project plan Hand over from OCE to Developer Services developer.trustedfirmware.org For the checkpatch job, it is a part of the static check stage, the error from this stage won't impact the final CI score, we need more investigation before active all static checks. The CI jobs were not able to trigger manually. There is a request to Linaro for the requirement that already working on, hope it can be deployed to the public Open CI soon. Job list example on Gerrit after CI job: Passed: 4, Failed: 18, Not done: 0 AN519_GNUARM_ConfigRegressionIPCTfmLevel2_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29147/> -1 AN519_GNUARM_ConfigRegressionIPC_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29146/> -1 AN519_GNUARM_ConfigRegressionProfileS_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29152/> -1 AN519_GNUARM_ConfigRegression_Release_BL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29144/> -1 .... checkpatch<http://ci.trustedfirmware.org/job/tf-m-checkpatch/472/> -1 cppcheck<http://ci.trustedfirmware.org/job/tf-m-cppcheck/472/> 1 lava_boot<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 lava_test<http://ci.trustedfirmware.org/job/tf-m-build-and-test/474/> 1 psoc64_GNUARM_ConfigRegressionIPCTfmLevel2_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29157/> -1 psoc64_GNUARM_ConfigRegressionIPC_Release_NOBL2<http://ci.trustedfirmware.org/job/tf-m-build-config/29154/> -1 tf-m-build<http://ci.trustedfirmware.org/job/tf-m-build-and-test/479/> -1 tf-m-build-docs<http://ci.trustedfirmware.org/job/tf-m-build-docs/647/> 1 Thanks, Karl Zhang ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, September 1, 2020 12:35 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] CI Checkpatch So I see the CI system runs checkpatch, but I don’t see any mention of checkpatch under the “docs” directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 7 months

1
0
0 0

[RFC] The code review guideline

by Ken Liu

Hi, We are creating one document to describe the code review guidelines: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5372 The goal of this document is to introduce the source management level concepts to be followed while reviewing a code – which try to simplify the contribution (but burdens the reviewers? 😉). Difference to the `coding style`: * It focuses more on the source placement, interface definition and including, etc. As this document is keeping evolving in a period, the plan is we merge a simple version as start and adding more contents by new patches, so please give enough comments if you have, and don’t forget the concept: we want to make things rational and simple. Thanks. /Ken

4 years, 8 months

1
0
0 0

psa_key_id_t type mismatch --- HardFault

by Alamy Liu

Dear all, While I was working on the PSoC64 platform, I hit the *psa_key_id_t* type mismatch problem. The patch - *98ab441e096f *enables *MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER* Which in terms to use the *psa_key_id_t* *structure* (psa_key_file_id_t) in <mbed-crypto/mbedtls>/include/psa/*crypto_platform.h* Interestingly, psa_key_id_t is also defined in <tf-m>/interface/include/psa/ *crypto_types.h*, as a uint32_t. So, I do the following testing I could compile the master HEAD no problem *66ee5c8861* (HEAD, origin/master, origin/HEAD) Tools: update iat-verifier README and samples I assume the psa_key_id_t should be a *structure* (from mbed-crypto/mbedtls), I applied the patch below --- a/interface/include/psa/crypto_types.h +++ b/interface/include/psa/crypto_types.h @@ -211,6 +211,8 @@ typedef uint8_t psa_key_persistence_t; */ typedef uint32_t psa_key_location_t;+#if !defined(MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER)+#error Should not compile this /** Encoding of identifiers of persistent keys. * * - Applications may freely choose key identifiers in the range @@ -222,6 +224,7 @@ typedef uint32_t psa_key_location_t; */ typedef uint32_t psa_key_id_t; #define PSA_KEY_ID_INIT 0+#endif Then, I notice that there are still many files that use *uint32_t* psa_key_id_t in the TF-M source tree. a) It's good (lucky?) that TF-M seems to cut it cleanly so it doesn't run into problems (well, it happens on PSoC64, or I won't notice it). b) It's bad that psa_key_id_t in TF-M has two different types. I'm not going to argue what's correct/wrong. Maybe this kind of coding could be a feature in the future. I just go with it. But I found no information to define the boundary of the two types under the <tf-m>/docs/ directory. I would like to know where the boundary is, in TF-M. In other words, *Which part of the code should use the structure definition from mbedtls/mbed-crypto; which part of the code should use uint32_t ?* In my work, the problem happens when it passes psa_key_id_t as a parameter, the parent & child functions see it differently (HardFault, in my case, memory violation to other parameters). e.g.: func_a.c (structure), func_b.c (uint32_t). func_b.h ---- the type changes when it's included by func_a.c and/or func_b.c Regards, Alamy

4 years, 8 months

1
1
0 0

CI Checkpatch

by Christopher Brand

So I see the CI system runs checkpatch, but I don't see any mention of checkpatch under the "docs" directory, or in any of the gerrit reviews, or even on the mailing list. The output in the CI system, as far as I can see, is not particularly useful (I followed the link posted on my review to https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-static/detai… but could find anything indicating what issue was actually found). Is there any documentation on how we can run checkptach manually? Or on how to see what the CI version is actually complaining about? Should I just be ignoring the CI checkpatch errors? Thanks, Chris Brand Sr Prin Software Engr, MCD: WIRELESS Cypress Semiconductor Corp. An Infineon Technologies Company #320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com> This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

4 years, 8 months

1
0
0 0

Changes to configure FPU at the architectural level in TF-M

by Jamie Fox

Hi all, There is a change open for review that adds configuration of FPU-related registers to the architecture-abstraction layer in TF-M, and removes this same configuration from platform support files. The reasoning for this is that these registers are defined by the Arm architecture, so FPU config can be unified for all platforms with the same architecture. For Armv8-M, this also includes configuration to ensure that information is not leaked in FPU registers to NSPE when the SPE uses the FPU, and to permit the NSPE to access the FPU. By default, TF-M will still be built without the FPU used in the SPE. You can review the changes at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5405 Arch: Add function to configure coprocessors https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5406 Platform: Remove platform-specific FPU config It would be especially helpful if platform owners could check that they are happy with FPU config being moved out of the platform support files. Kind regards, Jamie

4 years, 8 months

1
0
0 0

ST platforms building broken

by Kevin Peng

Hi Michel, Some of the configurations on ST platform building is broken. Please see the details in the following ticket: https://developer.trustedfirmware.org/T808 Would you please have a look. Thanks. Best Regards, Kevin

4 years, 8 months

1
0
0 0

TF-M Technical Forum call - September 3

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, September 3 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 Komlev

4 years, 8 months

1
0
0 0

Re: [TF-M] New build system with IAR

by David Hu

Hi Thomas, Sorry if I misunderstand your problem. Does it mean that diverse compilers require different core config flags? Best regards, Hu Ziji ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, August 25, 2020 7:39 PM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] New build system with IAR I've started looking at the new build system, and it looks like a nice improvement. I have a problem, that likely has a simple solution, although I'm not sure which. I've looked at the AN521 target, and the preload.cmake file is included very early from the root CMakeLists.txt The first line of preload.cmake is: --- set(CMAKE_SYSTEM_PROCESSOR cortex-m33+nodsp) --- For IAR that line should be: --- set(CMAKE_SYSTEM_PROCESSOR Cortex-M33.no_dsp) --- I need to discriminate between the toolchains already there, but I haven't figured out what the best way would be to do that. Not much is setup at this moment in the run. Ideas? Thomas -- Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

4 years, 8 months

2
2
0 0

Re: [TF-M] New build system with IAR

by Gyorgy Szing

Hi, CMAKE_SYSTEM_PROCESSOR identifies the CPU the build targets. If this string is passed to the compiler as a command line flag, that seems to be an error to me. Also I have the feeling that this value should be more hardware specific. A Cortex-M33 CPU has many configuration options to be set when it is put into a system, and different set of options may need different compiler switches. All this complexity might not be needed in the build-system and it could be better to hide it. I suggest naming the CMAKE_SYSTEM_PROCESSOR after the "chip" (i.e. AN521). The compiler specific files can map this name to the appropriate set of compiler options, and the compiler will set the "feature test macros" described in [1]. Source code can use these macros to configure itself properly. In the build system only features having an effect on CMake files shall be visible. (I.e. if a feature needs a different file to be compiled in.) [1] https://developer.arm.com/documentation/101028/0011/Feature-test-macros?lan… /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 25 August 2020 15:56 To: David Hu <David.Hu(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] New build system with IAR Hi David, Apparently yes. Here are the valid M33 choices for IAR: --- thomasto@ubuntu-20:~/tf-m1/trusted-firmware-m$ iccarm --cpu list|grep -i m33 Cortex-M33 Cortex-M33.no_dsp Cortex-M33.fp Cortex-M33.fp.no_dsp Cortex-M33.no_se Cortex-M33.no_dsp.no_se Cortex-M33.fp.no_se Cortex-M33.fp.no_dsp.no_se --- Cheers, Thomas Den 2020-08-25 kl. 15:49, skrev David Hu: Hi Thomas, Sorry if I misunderstand your problem. Does it mean that diverse compilers require different core config flags? Best regards, Hu Ziji ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org> Sent: Tuesday, August 25, 2020 7:39 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] New build system with IAR I've started looking at the new build system, and it looks like a nice improvement. I have a problem, that likely has a simple solution, although I'm not sure which. I've looked at the AN521 target, and the preload.cmake file is included very early from the root CMakeLists.txt The first line of preload.cmake is: --- set(CMAKE_SYSTEM_PROCESSOR cortex-m33+nodsp) --- For IAR that line should be: --- set(CMAKE_SYSTEM_PROCESSOR Cortex-M33.no_dsp) --- I need to discriminate between the toolchains already there, but I haven't figured out what the best way would be to do that. Not much is setup at this moment in the run. Ideas? Thomas -- Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> -- Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

4 years, 8 months

1
0
0 0

Re: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0)

by Soby Mathew

Just an update to this, I have merged the patch which upgrades to the latest mbedTLS tag. The PSA Arch initial attestation test suite fails to build after this merge due to width change of `ecc_curve_t` type. The issue is reported here in PSA Arch test github project : https://github.com/ARM-software/psa-arch-tests/pull/232 The patch for changing the ITS_MAX_ASSET_SIZE is still outstanding and I hope to merge it after a week. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 11 August 2020 16:24 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0) Hi Everyone The following patch updates the crypto service in TF-M to use the latest mbedTLS tag v2.23.0. All reviews for the same will be much appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5252/1 With this update, additional PSA APIs psa_hash_compute() and psa_hash_compare() are now supported. There is also another patch for platforms to update the ITS_MAX_ASSET_SIZE when testing with PSA Crypto API compliance test as one of the tests require a larger size: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5253/1 . Could the platform owners review the same and let me know whether the size changes are OK ? With the above patches, the API compliance remains the same as v1.0 Beta 3 and the PSA Crypto compliance test suite gives the below results (as tested on AN521) : ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 42 TOTAL SIM ERROR : 0 TOTAL FAILED : 17 TOTAL SKIPPED : 2 ****************************************** Best Regards Soby Mathes

4 years, 8 months

1
0
0 0

Re: [TF-M] Deprecate AN539 platform

by Soby Mathew

Thanks Andrew for the update. Just to confirm that AN521 is not affected. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Murray via TF-M Sent: 20 August 2020 08:04 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Deprecate AN539 platform Hi Thomas :) Thanks for that note about the AN521. I've just checked and I was mistaken - it is in fact the AN521 that I am using (rather than the AN539). I therefore have no objection to the deprecation. Sorry about wasting your time :( Andrew ;) -- Andrew Murray indie Semiconductor |Technical Director | MCU Architectures & Security ---------- Forwarded message ---------- From: "Thomas Törnblom" <thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com>> To: <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: Bcc: Date: Thu, 20 Aug 2020 08:51:34 +0200 Subject: Re: [TF-M] Deprecate AN539 platform AN521 is also mps2+/m33.

4 years, 8 months

1
0
0 0

Re: [TF-M] Deprecate AN539 platform

by Andrew Murray

Hi Thomas :) Thanks for that note about the AN521. I've just checked and I was mistaken - it is in fact the AN521 that I am using (rather than the AN539). *I therefore have no objection to the deprecation*. Sorry about wasting your time :( Andrew ;) *--* *Andrew Murray* *indie Semiconductor |Technical Director | MCU Architectures & Security* ---------- Forwarded message ---------- From: "Thomas Törnblom" <thomas.tornblom(a)iar.com> To: <tf-m(a)lists.trustedfirmware.org> Cc: Bcc: Date: Thu, 20 Aug 2020 08:51:34 +0200 Subject: Re: [TF-M] Deprecate AN539 platform AN521 is also mps2+/m33.

4 years, 8 months

1
0
0 0

-DBL2=False causes duplicates in ASM_FLAGS in makefiles

by Thomas Törnblom

For some reason that I've not been able to track down, using -DBL2=False on the cmake command line causes ASM_FLAGS to have duplicated debug flags and defines. It does not happen to C_FLAGS and it doesn't happen with -DBL2=True. I've worked around the issue in https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5365, but a cleaner solution would be to avoid this in the first place. I would appreciate if someone with more cmake experience could have a go at this. It causes build failures with IAR, and ARMCLANG and GNUARM doesn't care about the duplicates. Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 8 months

1
0
0 0

Re: [TF-M] Deprecate AN539 platform

by Thomas Törnblom

AN521 is also mps2+/m33. Den 2020-08-20 kl. 08:48, skrev Andrew Murray via TF-M: > Hi Soby ;) > > I'm currently using an MPS2+ board with the AN539 system to experiment > with TF-M code for a new M33-based, IC design. Does "deprecating the > AN539 platform" effectively mean deprecating TF-M support for the > MPS2+ FPGA platform entirely? In other words: is AN539 the only > example subsystem for the MPS2+ board that supports the M33 and TF-M? > If it is, then I'd like to object (for what that's worth!) > > (Feel free to try to persuade me of the merits of an alternative > prototyping platform.) > > Andrew ;) > > /--/ > > /Andrew Murray/ > > /indie Semiconductor |Technical Director | MCU Architectures & Security/ > > // > > > > ... > From: Soby Mathew <Soby.Mathew(a)arm.com <mailto:Soby.Mathew@arm.com>> > To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org > <mailto:tf-m@lists.trustedfirmware.org>> > Cc: > Bcc: > Date: Mon, 17 Aug 2020 14:11:36 +0000 > Subject: [TF-M] Deprecate AN539 platform > > Hi Everyone, > > As mentioned in > https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/contr…, > we would like to propose the deprecation of AN539 MPS2 platform and > remove the same from TF-M master after next release. As per the > process, this proposal will be open for discussion for a period of 4 > weeks and if there are no major objections, the platform will be > marked as deprecated. > > Thanks & Regards > > Soby Mathew > > -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M