- TF-M - lists.trustedfirmware.org

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

by Tamas Ban

Hi Anton, I would like to give a short presentation about crypto code sharing between bootloader and runtime firmware(SPE). Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 03 June 2020 21:21 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - June 11 Hello, The next Technical Forum is planned on Thursday, June 11 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Here are some local time examples: Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 11 June 2020, 08:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 11 June 2020, 10:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 11 June 2020, 16:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 11 June 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 11 June 2020, 15:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200611T1500> Best regards, Anton Komlev

5 years, 5 months

1
0
0 0

Re: [TF-M] build error

by Gyorgy Szing

Hi, Can you please run the build with "cmake -build ./ -- install VERBOSE=1". This will show compiler command lines which could help. Based on the fact your assembler is complaining not understanding assembly instructions generated by the C compiler, I suspect your compiler is not supported. For "arm-none-eabi-cc -v" I get the following output: ....... gcc version 6.3.1 20170215 (release) [ARM/embedded-6-branch revision 245512] (GNU Tools for ARM Embedded Processors 6-2017-q1-update) (Note I removed some not so interesting lines.) As you can see, the version string includes the release name of "6-2017-q1-update". All gcc binaries built by arm shall have this. Please double check what compiler you are using. The last bullet point in the blue "notes" section here: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… has the link to the download site and also names the releases you can use. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shawn Shan via TF-M Sent: 04 June 2020 10:21 To: Quach, Brian <brian(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] build error Hi Brian, I would like to correct my last Email: * CMSIS_5 version should be v5.5.0. * Mbedtls is not required anymore. Please refer to the "build instructions" link for the detail: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…. I have tried to reproduce your issue on my side but failed. So please try it again after changing the code version. Besides this, you can also check whether your build environment follows the TF-M user guides: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…. Please connect us again if you met any problems. Thanks, Shawn From: Quach, Brian <brian(a)ti.com<mailto:brian@ti.com>> Sent: Wednesday, June 3, 2020 3:09 AM To: Shawn Shan <Shawn.Shan(a)arm.com<mailto:Shawn.Shan@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: build error Hi Shawn, Yes, I emptied the cmake_build directory. I tried a fresh clone of the tags you specified but still get the same error. I'm using GNU Arm version mentioned in the TF-M user guide (v6.3.1) gcc version 6.3.1 20170620 (15:6.3.1+svn253039-1build1) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/trusted-firmware-m (master) $ git log commit b157dca40dcf2051a0420cb16d659a6aa69335d7 (HEAD -> master, origin/master, origin/HEAD) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/mbed-crypto ((mbedcrypto-3.0.1)) $ git log commit 1146b4e06011b69a6437e6b728f2af043a06ec19 (HEAD, tag: mbedcrypto-3.0.1) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/mbedtls ((mbedtls-2.7.9)) $ git log commit 3187e7ca986fe199313343b0c810e41b543ef78a (HEAD, tag: mbedtls-2.7.9) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/CMSIS_5 (Branch_5.2.0) $ git log commit 80cc44bba16cb4c8f495b7aa9709d41ac50e9529 (HEAD -> Branch_5.2.0, tag: 5.2.0) Scanning dependencies of target tfm_s_pp_image_macros_to_preprocess_s_1 [ 0%] Preprocess the /mnt/c/Gits/tfm/trusted-firmware-m/cmake_build/image_macros_to_preprocess_s.c file [ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1 Scanning dependencies of target tfm_s_pp_tfm_common_s_1 [ 0%] Preprocess the /mnt/c/Gits/tfm/trusted-firmware-m/platform/ext/common/gcc/tfm_common_s.ld file [ 0%] Built target tfm_s_pp_tfm_common_s_1 Scanning dependencies of target tfm_s_obj_lib [ 1%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_api.o [ 1%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o /tmp/ccmASnGm.s: Assembler messages: /tmp/ccmASnGm.s:47: Error: syntax error -- `msr psplim,r3' secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1 CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 Regards, Brian From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Shawn Shan via TF-M Sent: Monday, June 01, 2020 10: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: [EXTERNAL] Re: [TF-M] build error Hi Brian, Did you empty the build directory before you build? And this is the recommended commit id for each of the repositories: Mbed-crypto: 1146b4e06011b69a6437e6b728f2af043a06ec19 Tag mbedcrypto-3.0.1 Mbedtls: 3187e7ca986fe199313343b0c810e41b543ef78a Tag mbedtls-2.7.9 CMSIS_5: 80cc44bba16cb4c8f495b7aa9709d41ac50e9529 Tag 5.2.0 Could you share us the commit id of each repo and the toolchain version (arm-none-eabi-gcc -v) you are using? Thanks, Shawn From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Quach, Brian via TF-M Sent: Tuesday, June 2, 2020 7:25 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] build error Hi All, I'm using the latest TF-M, embedTLS, and CMSIS 5 code (repo HEAD). I renamed embedtls to embed-crypto. I ran "cmake ../ -G"Unix Makefiles" -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM" which seemed to execute fine, but I'm getting an error on the next step. Does anyone know the solution? mnt/c/Gits/trusted-firmware-m/cmake_build$ cmake --build ./ -- install [ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1 [ 0%] Built target tfm_s_pp_tfm_common_s_1 [ 0%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o /tmp/ccpVCp1C.s: Assembler messages: /tmp/ccpVCp1C.s:47: Error: syntax error -- `msr psplim,r3' secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1 CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 5 months

1
0
0 0

Re: [TF-M] build error

by Shawn Shan

Hi Brian, I would like to correct my last Email: * CMSIS_5 version should be v5.5.0. * Mbedtls is not required anymore. Please refer to the "build instructions" link for the detail: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…. I have tried to reproduce your issue on my side but failed. So please try it again after changing the code version. Besides this, you can also check whether your build environment follows the TF-M user guides: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…. Please connect us again if you met any problems. Thanks, Shawn From: Quach, Brian <brian(a)ti.com> Sent: Wednesday, June 3, 2020 3:09 AM To: Shawn Shan <Shawn.Shan(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: build error Hi Shawn, Yes, I emptied the cmake_build directory. I tried a fresh clone of the tags you specified but still get the same error. I'm using GNU Arm version mentioned in the TF-M user guide (v6.3.1) gcc version 6.3.1 20170620 (15:6.3.1+svn253039-1build1) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/trusted-firmware-m (master) $ git log commit b157dca40dcf2051a0420cb16d659a6aa69335d7 (HEAD -> master, origin/master, origin/HEAD) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/mbed-crypto ((mbedcrypto-3.0.1)) $ git log commit 1146b4e06011b69a6437e6b728f2af043a06ec19 (HEAD, tag: mbedcrypto-3.0.1) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/mbedtls ((mbedtls-2.7.9)) $ git log commit 3187e7ca986fe199313343b0c810e41b543ef78a (HEAD, tag: mbedtls-2.7.9) a0270932@LT74BFJR2 MINGW64 /c/Gits/tfm/CMSIS_5 (Branch_5.2.0) $ git log commit 80cc44bba16cb4c8f495b7aa9709d41ac50e9529 (HEAD -> Branch_5.2.0, tag: 5.2.0) Scanning dependencies of target tfm_s_pp_image_macros_to_preprocess_s_1 [ 0%] Preprocess the /mnt/c/Gits/tfm/trusted-firmware-m/cmake_build/image_macros_to_preprocess_s.c file [ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1 Scanning dependencies of target tfm_s_pp_tfm_common_s_1 [ 0%] Preprocess the /mnt/c/Gits/tfm/trusted-firmware-m/platform/ext/common/gcc/tfm_common_s.ld file [ 0%] Built target tfm_s_pp_tfm_common_s_1 Scanning dependencies of target tfm_s_obj_lib [ 1%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_api.o [ 1%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o /tmp/ccmASnGm.s: Assembler messages: /tmp/ccmASnGm.s:47: Error: syntax error -- `msr psplim,r3' secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1 CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 Regards, Brian From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Shawn Shan via TF-M Sent: Monday, June 01, 2020 10: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: [EXTERNAL] Re: [TF-M] build error Hi Brian, Did you empty the build directory before you build? And this is the recommended commit id for each of the repositories: Mbed-crypto: 1146b4e06011b69a6437e6b728f2af043a06ec19 Tag mbedcrypto-3.0.1 Mbedtls: 3187e7ca986fe199313343b0c810e41b543ef78a Tag mbedtls-2.7.9 CMSIS_5: 80cc44bba16cb4c8f495b7aa9709d41ac50e9529 Tag 5.2.0 Could you share us the commit id of each repo and the toolchain version (arm-none-eabi-gcc -v) you are using? Thanks, Shawn From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Quach, Brian via TF-M Sent: Tuesday, June 2, 2020 7:25 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] build error Hi All, I'm using the latest TF-M, embedTLS, and CMSIS 5 code (repo HEAD). I renamed embedtls to embed-crypto. I ran "cmake ../ -G"Unix Makefiles" -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM" which seemed to execute fine, but I'm getting an error on the next step. Does anyone know the solution? mnt/c/Gits/trusted-firmware-m/cmake_build$ cmake --build ./ -- install [ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1 [ 0%] Built target tfm_s_pp_tfm_common_s_1 [ 0%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o /tmp/ccpVCp1C.s: Assembler messages: /tmp/ccpVCp1C.s:47: Error: syntax error -- `msr psplim,r3' secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1 CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 5 months

1
0
0 0

Re: [TF-M] [IMPORTANT] [SOURCE STRUCTURE] The first structure adjust patch is pushed

by Ken Liu

Hi, There are few comments on the structure document, so let's merge the first patch as a signal. This merging does not mean it is the decided shape - the structure related comments are always open, feedback on the mailing list or the task: https://developer.trustedfirmware.org/T751 Or, to be direct, put comments on the ongoing updates to the design doc: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4415 Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, June 1, 2020 2:11 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [IMPORTANT] [SOURCE STRUCTURE] The first structure adjust patch is pushed Hi, As the first commit of 'source_structure' document is merged, here is the first patch to follow the document: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4315 The patch looks big, even it just adjusts the content inside 'secure_fw'. To make the related sources can pass the building, some files out of the 'secure_fw' need to be changed. The goal of merging is ASAP so that we won't block upcoming features. Please provide the feedback about potential USAGE problem you may meet. As the patch is big, it won't be applicable to make THIS patch perfect to meet all the requirements defined in the document, a series of upcoming patches would come as amending. Also if there are suggestions about the structure document, please write to the mailing list and put discussion in this task: https://developer.trustedfirmware.org/T751 The rendered structure document: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/252/artifact/bui… BR /Ken

5 years, 5 months

1
0
0 0

[RFC] [Logging API] Design document call for review

by Shawn Shan

Hi all, I have created a draft design document of the TF-M logging system. Could you please help review it https://review.trustedfirmware.org/c/trusted-firmware-m/+/4417 ? Welcome your comments and suggestions.😊 Best regards, Shawn

5 years, 5 months

1
0
0 0

TF-M Technical Forum call - June 11

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, June 11 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Here are some local time examples: Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 11 June 2020, 08:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 11 June 2020, 10:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 11 June 2020, 16:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 11 June 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 11 June 2020, 15:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200611T1500> Best regards, Anton Komlev

5 years, 5 months

1
0
0 0

Re: [TF-M] Changes required to enable Zephyr integration as External_Project

by Tamas Ban

Hi Kumar, We are going to check and merge changes from Kevin before v1.1 release. Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: 03 June 2020 13:02 To: Anton Komlev <Anton.Komlev(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Changes required to enable Zephyr integration as External_Project Than I ask that the changes Kevin has posted be looked at for TFM v1.1 as the are relatively small and than the CMake rework can be done on top of them if its able to land for v1.1. - k > On Jun 3, 2020, at 3:30 AM, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > There was a plan to include the new build system into TFM v1.1 but looking onto change size and interdependencies with other ongoing changes like code restructuring, the delivery of new CMake in TFM v1.1 is optional. > The intention is to be safe and test more instead of delivery ahead and fix later. > > Anton > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar > Gala via TF-M > Sent: 02 June 2020 13:50 > To: Raef Coles <Raef.Coles(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Changes required to enable Zephyr integration as > External_Project > > What’s the timeframe expectation with the new cmake work? Is this something that is planned for TFM 1.1? > > - k > >> On Jun 2, 2020, at 7:11 AM, Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi, >> >> Thank you very much for the changes to the image signing script - those look like great QOL improvements. >> >> WRT Ninja and externalproject support, there is currently an ongoing effort to improve the TF-M build system by rewriting it to use more modern and streamlined cmake. I haven't tested it as an externalproject yet, but am pretty confident that it should now work "out of the box". When it gets to the stage that it can be submitted to trustedfirmware.org as a patch I'll try to reply to this so you can test that. >> >> I personally hadn't used Ninja much, but am pleasantly surprised with how fast it is. I will do my best to make sure that the new cmake also works with ninja, since support should be relatively simple. >> >> Raef >> >> ________________________________________ >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of >> Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> >> Sent: 02 June 2020 12:11 >> To: Thomas Törnblom via TF-M >> Subject: [TF-M] Changes required to enable Zephyr integration as >> External_Project >> >> Hi, >> >> The following task lists some of the changes that we had to make to >> enable TF-M to be built using ExternalProject_Add from Zephyr, as >> well as enabling the use of ninja for TF-M builds (which is often >> significantly faster than using classic >> makefiles): https://developer.trustedfirmware.org/T760 >> >> The ninja changes have been tested with: >> >> $ cmake -GNinja -DPROJ_CONFIG=`readlink -f ../configs/ConfigDefault.cmake` -DTARGET_PLATFORM=LPC55S69 -DBL2=False -DCOMPILER=GNUARM .. >> $ ninja >> >> The changes to imgtool.py resolve some platform issues when signing binaries, and add a convenience requirements.txt file that can be run in CI to ensure that all of the Python dependencies are met for this tool. >> >> Any concerns or feedback on these are welcome, but I would be >> interested to hear any opinions on ninja which is often considerably >> faster out of the box when compiling (at least on Linux and native OS X, which is what I use for my builds). >> >> Best regards, >> Kevin >> -- >> 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 > -- > 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

5 years, 5 months

1
0
0 0

Re: [TF-M] Changes required to enable Zephyr integration as External_Project

by Kumar Gala

Than I ask that the changes Kevin has posted be looked at for TFM v1.1 as the are relatively small and than the CMake rework can be done on top of them if its able to land for v1.1. - k > On Jun 3, 2020, at 3:30 AM, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > There was a plan to include the new build system into TFM v1.1 but looking onto change size and interdependencies with other ongoing changes like code restructuring, the delivery of new CMake in TFM v1.1 is optional. > The intention is to be safe and test more instead of delivery ahead and fix later. > > Anton > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M > Sent: 02 June 2020 13:50 > To: Raef Coles <Raef.Coles(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Changes required to enable Zephyr integration as External_Project > > What’s the timeframe expectation with the new cmake work? Is this something that is planned for TFM 1.1? > > - k > >> On Jun 2, 2020, at 7:11 AM, Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi, >> >> Thank you very much for the changes to the image signing script - those look like great QOL improvements. >> >> WRT Ninja and externalproject support, there is currently an ongoing effort to improve the TF-M build system by rewriting it to use more modern and streamlined cmake. I haven't tested it as an externalproject yet, but am pretty confident that it should now work "out of the box". When it gets to the stage that it can be submitted to trustedfirmware.org as a patch I'll try to reply to this so you can test that. >> >> I personally hadn't used Ninja much, but am pleasantly surprised with how fast it is. I will do my best to make sure that the new cmake also works with ninja, since support should be relatively simple. >> >> Raef >> >> ________________________________________ >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin >> Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> >> Sent: 02 June 2020 12:11 >> To: Thomas Törnblom via TF-M >> Subject: [TF-M] Changes required to enable Zephyr integration as >> External_Project >> >> Hi, >> >> The following task lists some of the changes that we had to make to >> enable TF-M to be built using ExternalProject_Add from Zephyr, as well >> as enabling the use of ninja for TF-M builds (which is often >> significantly faster than using classic >> makefiles): https://developer.trustedfirmware.org/T760 >> >> The ninja changes have been tested with: >> >> $ cmake -GNinja -DPROJ_CONFIG=`readlink -f ../configs/ConfigDefault.cmake` -DTARGET_PLATFORM=LPC55S69 -DBL2=False -DCOMPILER=GNUARM .. >> $ ninja >> >> The changes to imgtool.py resolve some platform issues when signing binaries, and add a convenience requirements.txt file that can be run in CI to ensure that all of the Python dependencies are met for this tool. >> >> Any concerns or feedback on these are welcome, but I would be >> interested to hear any opinions on ninja which is often considerably >> faster out of the box when compiling (at least on Linux and native OS X, which is what I use for my builds). >> >> Best regards, >> Kevin >> -- >> 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 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Invitation: TF-M Tech Forum (US TZ) @ Thu 25 Jun 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 (US TZ) ** 25th June call rescheduled (due to holidays in China) **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 25 Jun 2020 16:00 – 17:00 United Kingdom Time Where: Via Zoom Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MGFmdnVlcmltYjB1M2Y1O… 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

5 years, 5 months

1
0
0 0

Cancelled event with note: TF-M tech Forum (Asia TZ) @ Thu 25 Jun 2020 07:00 - 08:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "Due to holidays in China, the event in this time slot is cancelled. " Title: TF-M tech Forum (Asia TZ) 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 25 Jun 2020 07:00 – 08:00 United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * 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

5 years, 5 months

1
0
0 0

Re: [TF-M] TF-M PSA key management

by Soby Mathew

Hi Brian, The struct you have mentioned is part of the implementation defined `psa_key_attributes_t` data structure. The key algorithm and policy are accessed via appropriate get/set API's (like psa_set_key_algorithm/ psa_get_key_algorithm). Hence these fields are not meant to be directly accessed by the clients but are an implementation detail of crypto Service. The only reason the 2 algorithm fields exists now is because the mbedcrypto defined the structure that way. I have a patch in flight which cleans up the client view of the psa_key_attributes_t such that only fields required by client are defined. The patch is available for review here : https://review.trustedfirmware.org/c/trusted-firmware-m/+/4217 Regarding psa_open_key() and psa_close_key(), TF-M tries to implement PSA Crypto 1.0 Beta 3 version of the spec whereas the APIs are removed in 1.0 version. Currently mbedcrypto does not support 1.0 version fully yet. Once 1.0 is supported mbedcrypto, then TF-M will also make the migrate the APIs to 1.0. This is expected to happen during Q3 timeframe. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Quach, Brian via TF-M Sent: 02 June 2020 23:44 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M PSA key management Hi All, I see that the PSA crypto API v1.0 spec says "This specification only defines policies that restrict keys to a single algorithm, which is consistent with both common practice and security good practice. ", but the TF-M code defines two algs in the policy struct. Which will be the path going forward? struct psa_key_policy_s { psa_key_usage_t usage; psa_algorithm_t alg; psa_algorithm_t alg2; }; I also see psa_open_key() and psa_close_key() were removed from the spec. Any plans to remove from TF-M code in the future? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 5 months

1
0
0 0

Re: [TF-M] Changes required to enable Zephyr integration as External_Project

by Anton Komlev

Hi, There was a plan to include the new build system into TFM v1.1 but looking onto change size and interdependencies with other ongoing changes like code restructuring, the delivery of new CMake in TFM v1.1 is optional. The intention is to be safe and test more instead of delivery ahead and fix later. Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: 02 June 2020 13:50 To: Raef Coles <Raef.Coles(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Changes required to enable Zephyr integration as External_Project What’s the timeframe expectation with the new cmake work? Is this something that is planned for TFM 1.1? - k > On Jun 2, 2020, at 7:11 AM, Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Thank you very much for the changes to the image signing script - those look like great QOL improvements. > > WRT Ninja and externalproject support, there is currently an ongoing effort to improve the TF-M build system by rewriting it to use more modern and streamlined cmake. I haven't tested it as an externalproject yet, but am pretty confident that it should now work "out of the box". When it gets to the stage that it can be submitted to trustedfirmware.org as a patch I'll try to reply to this so you can test that. > > I personally hadn't used Ninja much, but am pleasantly surprised with how fast it is. I will do my best to make sure that the new cmake also works with ninja, since support should be relatively simple. > > Raef > > ________________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin > Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: 02 June 2020 12:11 > To: Thomas Törnblom via TF-M > Subject: [TF-M] Changes required to enable Zephyr integration as > External_Project > > Hi, > > The following task lists some of the changes that we had to make to > enable TF-M to be built using ExternalProject_Add from Zephyr, as well > as enabling the use of ninja for TF-M builds (which is often > significantly faster than using classic > makefiles): https://developer.trustedfirmware.org/T760 > > The ninja changes have been tested with: > > $ cmake -GNinja -DPROJ_CONFIG=`readlink -f ../configs/ConfigDefault.cmake` -DTARGET_PLATFORM=LPC55S69 -DBL2=False -DCOMPILER=GNUARM .. > $ ninja > > The changes to imgtool.py resolve some platform issues when signing binaries, and add a convenience requirements.txt file that can be run in CI to ensure that all of the Python dependencies are met for this tool. > > Any concerns or feedback on these are welcome, but I would be > interested to hear any opinions on ninja which is often considerably > faster out of the box when compiling (at least on Linux and native OS X, which is what I use for my builds). > > Best regards, > Kevin > -- > 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

5 years, 5 months

1
0
0 0

TF-M PSA key management

by Quach, Brian

Hi All, I see that the PSA crypto API v1.0 spec says "This specification only defines policies that restrict keys to a single algorithm, which is consistent with both common practice and security good practice. ", but the TF-M code defines two algs in the policy struct. Which will be the path going forward? struct psa_key_policy_s { psa_key_usage_t usage; psa_algorithm_t alg; psa_algorithm_t alg2; }; I also see psa_open_key() and psa_close_key() were removed from the spec. Any plans to remove from TF-M code in the future? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 5 months

1
0
0 0

Re: [TF-M] DSP instructions and FPU use

by Joseph Yiu

Hi Ken, Soby, In additional to FPCCR_S.TS, You should also set FPCCR_S.CLRONRET and FPCCR_S.CLRONRETS. FPCCR_S.CLRONRET ensures that FPU register contents are cleared when return from a Secure exception to the Non-secure world, and FPCCR_S.CLRONRETS ensures that the Non-secure world cannot change the FPCCR_S.CLRONRET setting. Regards, Joseph From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 02 June 2020 04:36 To: Ken Liu <Ken.Liu(a)arm.com>; TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] DSP instructions and FPU use Hi Ken, I agree that FPCCR_S.TS (in addition to other setting for FP) should be set if FPU needs to be used in secure world. The FPCCR.LSPEN allows saving the context lazily which was what I was referring to previously. Eventhough the hardware is performing the stacking, the policy chosen (lazy stacking/stack always) affects interrupt latency which should be considered for the design for FPU usage in TF-M. 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: 01 June 2020 15:55 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] DSP instructions and FPU use Hi Soby & Andrej, The FP context is managed by hardware automatically in M-profile architecture. While booting we clear FPCA since we are not using FP under handler mode, we don't want FP get involved during initialization and need extra clean up job. But if a thread uses FP the FPCA is set to 1 automatically, and if exceptions are happening the FP context stacked automatically by hardware - the secure scheduler just keep the EXC_RETURN which contains FP context and finally recover it back. Which means if you enabled hardware FP unintentional it can work, the only place a problem may occur should be the non-secure preempting secure execution case. I think the only thing we are missing now is we did not set FPCCR_S.TS = 1 since we did not realize that user would enable FP in secure world. This would cause the FP register may contain secure information while Non-secure preempting secure execution. Need to go through the settings and double-check. So at least before we finish the estimation I think FPCCR_S.TS should be set to ensure the security. Andrej, have you set this bit while you are using hardware FP? Or just let it go (use default TF-M setting)? Thanks. /Ken From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Monday, June 1, 2020 5:25 PM To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@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: DSP instructions and FPU use Hi, For enabling floating point the ARMv8-M architecture allows the flowing possibilities : * Stacking the basic Floating-point context. * Stacking the basic Floating-point context and the additional Floating-point context. * Activation of Lazy Floating-point state preservation. The easiest way would be to enable FP context stacking for every context switch but it would impact every context switch irrespective of whether FP unit is used in that context or not . I guess this is the approach taken by Andrej ? . The Lazy Floating point state preservation would be better for performance but it would have additional complexity in managing the contexts. Just blue sky thinking here: There could be a middle ground wherein some partitions are allowed to use FP while others are not because they don't really need to. The ones allowed to use FP will need to cater for the additional stack requirement to save FP context. The actual save of the context can be done either on context switch to the partition or lazily. This approach could give the benefit of both performance and memory savings but it requires some analysis and design to be done in TF-M. 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: 01 June 2020 09:05 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] DSP instructions and FPU use Hi Andrej, You mean the hardware floatpoint can be used in the Secure Partition? That's a good information, can you share us the compiler flags about float-point you are using? Thanks. /Ken From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: Monday, June 1, 2020 2:46 PM 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: DSP instructions and FPU use FYI: >> Can you do some experiments on enabling hardware float point and see if it is working In our SDK, the LPC55S HW Float point is enabled for all TFM projects (Kel, GCC/MCUx), and it works. 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: Monday, June 1, 2020 8:41 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] DSP instructions and FPU use Hi Cindy, The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default. Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation. During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch. For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load). Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Cindy Chaumont via TF-M Sent: Friday, May 29, 2020 6:39 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] DSP instructions and FPU use Hello, I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image). About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file). Is there a reason for that? Maybe some performance reasons? About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions? Thank you in advance for the answer, Best regards, Cindy

5 years, 5 months

1
0
0 0

Re: [TF-M] Changes required to enable Zephyr integration as External_Project

by Kumar Gala

What’s the timeframe expectation with the new cmake work? Is this something that is planned for TFM 1.1? - k > On Jun 2, 2020, at 7:11 AM, Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Thank you very much for the changes to the image signing script - those look like great QOL improvements. > > WRT Ninja and externalproject support, there is currently an ongoing effort to improve the TF-M build system by rewriting it to use more modern and streamlined cmake. I haven't tested it as an externalproject yet, but am pretty confident that it should now work "out of the box". When it gets to the stage that it can be submitted to trustedfirmware.org as a patch I'll try to reply to this so you can test that. > > I personally hadn't used Ninja much, but am pleasantly surprised with how fast it is. I will do my best to make sure that the new cmake also works with ninja, since support should be relatively simple. > > Raef > > ________________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: 02 June 2020 12:11 > To: Thomas Törnblom via TF-M > Subject: [TF-M] Changes required to enable Zephyr integration as External_Project > > Hi, > > The following task lists some of the changes that we had to make to enable > TF-M to be built using ExternalProject_Add from Zephyr, as well as enabling the > use of ninja for TF-M builds (which is often significantly faster than using classic > makefiles): https://developer.trustedfirmware.org/T760 > > The ninja changes have been tested with: > > $ cmake -GNinja -DPROJ_CONFIG=`readlink -f ../configs/ConfigDefault.cmake` -DTARGET_PLATFORM=LPC55S69 -DBL2=False -DCOMPILER=GNUARM .. > $ ninja > > The changes to imgtool.py resolve some platform issues when signing binaries, and add a convenience requirements.txt file that can be run in CI to ensure that all of the Python dependencies are met for this tool. > > Any concerns or feedback on these are welcome, but I would be interested to hear > any opinions on ninja which is often considerably faster out of the box when compiling > (at least on Linux and native OS X, which is what I use for my builds). > > Best regards, > Kevin > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Changes required to enable Zephyr integration as External_Project

by Raef Coles

Hi, Thank you very much for the changes to the image signing script - those look like great QOL improvements. WRT Ninja and externalproject support, there is currently an ongoing effort to improve the TF-M build system by rewriting it to use more modern and streamlined cmake. I haven't tested it as an externalproject yet, but am pretty confident that it should now work "out of the box". When it gets to the stage that it can be submitted to trustedfirmware.org as a patch I'll try to reply to this so you can test that. I personally hadn't used Ninja much, but am pleasantly surprised with how fast it is. I will do my best to make sure that the new cmake also works with ninja, since support should be relatively simple. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 02 June 2020 12:11 To: Thomas Törnblom via TF-M Subject: [TF-M] Changes required to enable Zephyr integration as External_Project Hi, The following task lists some of the changes that we had to make to enable TF-M to be built using ExternalProject_Add from Zephyr, as well as enabling the use of ninja for TF-M builds (which is often significantly faster than using classic makefiles): https://developer.trustedfirmware.org/T760 The ninja changes have been tested with: $ cmake -GNinja -DPROJ_CONFIG=`readlink -f ../configs/ConfigDefault.cmake` -DTARGET_PLATFORM=LPC55S69 -DBL2=False -DCOMPILER=GNUARM .. $ ninja The changes to imgtool.py resolve some platform issues when signing binaries, and add a convenience requirements.txt file that can be run in CI to ensure that all of the Python dependencies are met for this tool. Any concerns or feedback on these are welcome, but I would be interested to hear any opinions on ninja which is often considerably faster out of the box when compiling (at least on Linux and native OS X, which is what I use for my builds). Best regards, Kevin

5 years, 5 months

1
0
0 0

Changes required to enable Zephyr integration as External_Project

by Kevin Townsend

Hi, The following task lists some of the changes that we had to make to enable TF-M to be built using ExternalProject_Add from Zephyr, as well as enabling the use of ninja for TF-M builds (which is often significantly faster than using classic makefiles): https://developer.trustedfirmware.org/T760 The ninja changes have been tested with: $ cmake -GNinja -DPROJ_CONFIG=`readlink -f ../configs/ConfigDefault.cmake` -DTARGET_PLATFORM=LPC55S69 -DBL2=False -DCOMPILER=GNUARM .. $ ninja The changes to imgtool.py resolve some platform issues when signing binaries, and add a convenience requirements.txt file that can be run in CI to ensure that all of the Python dependencies are met for this tool. Any concerns or feedback on these are welcome, but I would be interested to hear any opinions on ninja which is often considerably faster out of the box when compiling (at least on Linux and native OS X, which is what I use for my builds). Best regards, Kevin

5 years, 5 months

1
0
0 0

Re: [TF-M] DSP instructions and FPU use

by Soby Mathew

Hi Ken, I agree that FPCCR_S.TS (in addition to other setting for FP) should be set if FPU needs to be used in secure world. The FPCCR.LSPEN allows saving the context lazily which was what I was referring to previously. Eventhough the hardware is performing the stacking, the policy chosen (lazy stacking/stack always) affects interrupt latency which should be considered for the design for FPU usage in TF-M. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 01 June 2020 15:55 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] DSP instructions and FPU use Hi Soby & Andrej, The FP context is managed by hardware automatically in M-profile architecture. While booting we clear FPCA since we are not using FP under handler mode, we don't want FP get involved during initialization and need extra clean up job. But if a thread uses FP the FPCA is set to 1 automatically, and if exceptions are happening the FP context stacked automatically by hardware - the secure scheduler just keep the EXC_RETURN which contains FP context and finally recover it back. Which means if you enabled hardware FP unintentional it can work, the only place a problem may occur should be the non-secure preempting secure execution case. I think the only thing we are missing now is we did not set FPCCR_S.TS = 1 since we did not realize that user would enable FP in secure world. This would cause the FP register may contain secure information while Non-secure preempting secure execution. Need to go through the settings and double-check. So at least before we finish the estimation I think FPCCR_S.TS should be set to ensure the security. Andrej, have you set this bit while you are using hardware FP? Or just let it go (use default TF-M setting)? Thanks. /Ken From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Monday, June 1, 2020 5:25 PM To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@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: DSP instructions and FPU use Hi, For enabling floating point the ARMv8-M architecture allows the flowing possibilities : * Stacking the basic Floating-point context. * Stacking the basic Floating-point context and the additional Floating-point context. * Activation of Lazy Floating-point state preservation. The easiest way would be to enable FP context stacking for every context switch but it would impact every context switch irrespective of whether FP unit is used in that context or not . I guess this is the approach taken by Andrej ? . The Lazy Floating point state preservation would be better for performance but it would have additional complexity in managing the contexts. Just blue sky thinking here: There could be a middle ground wherein some partitions are allowed to use FP while others are not because they don't really need to. The ones allowed to use FP will need to cater for the additional stack requirement to save FP context. The actual save of the context can be done either on context switch to the partition or lazily. This approach could give the benefit of both performance and memory savings but it requires some analysis and design to be done in TF-M. 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: 01 June 2020 09:05 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] DSP instructions and FPU use Hi Andrej, You mean the hardware floatpoint can be used in the Secure Partition? That's a good information, can you share us the compiler flags about float-point you are using? Thanks. /Ken From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: Monday, June 1, 2020 2:46 PM 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: DSP instructions and FPU use FYI: >> Can you do some experiments on enabling hardware float point and see if it is working In our SDK, the LPC55S HW Float point is enabled for all TFM projects (Kel, GCC/MCUx), and it works. 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: Monday, June 1, 2020 8:41 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] DSP instructions and FPU use Hi Cindy, The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default. Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation. During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch. For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load). Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Cindy Chaumont via TF-M Sent: Friday, May 29, 2020 6:39 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] DSP instructions and FPU use Hello, I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image). About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file). Is there a reason for that? Maybe some performance reasons? About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions? Thank you in advance for the answer, Best regards, Cindy

5 years, 5 months

1
0
0 0

Re: [TF-M] build error

by Shawn Shan

Hi Brian, Did you empty the build directory before you build? And this is the recommended commit id for each of the repositories: Mbed-crypto: 1146b4e06011b69a6437e6b728f2af043a06ec19 Tag mbedcrypto-3.0.1 Mbedtls: 3187e7ca986fe199313343b0c810e41b543ef78a Tag mbedtls-2.7.9 CMSIS_5: 80cc44bba16cb4c8f495b7aa9709d41ac50e9529 Tag 5.2.0 Could you share us the commit id of each repo and the toolchain version (arm-none-eabi-gcc -v) you are using? Thanks, Shawn From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Quach, Brian via TF-M Sent: Tuesday, June 2, 2020 7:25 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] build error Hi All, I'm using the latest TF-M, embedTLS, and CMSIS 5 code (repo HEAD). I renamed embedtls to embed-crypto. I ran "cmake ../ -G"Unix Makefiles" -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM" which seemed to execute fine, but I'm getting an error on the next step. Does anyone know the solution? mnt/c/Gits/trusted-firmware-m/cmake_build$ cmake --build ./ -- install [ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1 [ 0%] Built target tfm_s_pp_tfm_common_s_1 [ 0%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o /tmp/ccpVCp1C.s: Assembler messages: /tmp/ccpVCp1C.s:47: Error: syntax error -- `msr psplim,r3' secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1 CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 5 months

1
0
0 0

build error

by Quach, Brian

Hi All, I'm using the latest TF-M, embedTLS, and CMSIS 5 code (repo HEAD). I renamed embedtls to embed-crypto. I ran "cmake ../ -G"Unix Makefiles" -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM" which seemed to execute fine, but I'm getting an error on the next step. Does anyone know the solution? mnt/c/Gits/trusted-firmware-m/cmake_build$ cmake --build ./ -- install [ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1 [ 0%] Built target tfm_s_pp_tfm_common_s_1 [ 0%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o /tmp/ccpVCp1C.s: Assembler messages: /tmp/ccpVCp1C.s:47: Error: syntax error -- `msr psplim,r3' secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1 CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 5 months

1
0
0 0

Re: [TF-M] DSP instructions and FPU use

by Soby Mathew

Hi, For enabling floating point the ARMv8-M architecture allows the flowing possibilities : * Stacking the basic Floating-point context. * Stacking the basic Floating-point context and the additional Floating-point context. * Activation of Lazy Floating-point state preservation. The easiest way would be to enable FP context stacking for every context switch but it would impact every context switch irrespective of whether FP unit is used in that context or not . I guess this is the approach taken by Andrej ? . The Lazy Floating point state preservation would be better for performance but it would have additional complexity in managing the contexts. Just blue sky thinking here: There could be a middle ground wherein some partitions are allowed to use FP while others are not because they don't really need to. The ones allowed to use FP will need to cater for the additional stack requirement to save FP context. The actual save of the context can be done either on context switch to the partition or lazily. This approach could give the benefit of both performance and memory savings but it requires some analysis and design to be done in TF-M. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 01 June 2020 09:05 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] DSP instructions and FPU use Hi Andrej, You mean the hardware floatpoint can be used in the Secure Partition? That's a good information, can you share us the compiler flags about float-point you are using? Thanks. /Ken From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: Monday, June 1, 2020 2:46 PM 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: DSP instructions and FPU use FYI: >> Can you do some experiments on enabling hardware float point and see if it is working In our SDK, the LPC55S HW Float point is enabled for all TFM projects (Kel, GCC/MCUx), and it works. 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: Monday, June 1, 2020 8:41 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] DSP instructions and FPU use Hi Cindy, The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default. Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation. During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch. For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load). Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Cindy Chaumont via TF-M Sent: Friday, May 29, 2020 6:39 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] DSP instructions and FPU use Hello, I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image). About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file). Is there a reason for that? Maybe some performance reasons? About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions? Thank you in advance for the answer, Best regards, Cindy

5 years, 5 months

2
1
0 0

Re: [TF-M] DSP instructions and FPU use

by Andrej Butok

FYI: >> Can you do some experiments on enabling hardware float point and see if it is working In our SDK, the LPC55S HW Float point is enabled for all TFM projects (Kel, GCC/MCUx), and it works. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, June 1, 2020 8:41 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] DSP instructions and FPU use Hi Cindy, The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default. Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation. During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch. For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load). Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Cindy Chaumont via TF-M Sent: Friday, May 29, 2020 6:39 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] DSP instructions and FPU use Hello, I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image). About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file). Is there a reason for that? Maybe some performance reasons? About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions? Thank you in advance for the answer, Best regards, Cindy

5 years, 5 months

2
1
0 0

Re: [TF-M] DSP instructions and FPU use

by Ken Liu

Hi Cindy, The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default. Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation. During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch. For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load). Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Cindy Chaumont via TF-M Sent: Friday, May 29, 2020 6:39 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] DSP instructions and FPU use Hello, I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image). About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file). Is there a reason for that? Maybe some performance reasons? About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions? Thank you in advance for the answer, Best regards, Cindy

5 years, 5 months

1
0
0 0

[IMPORTANT] [SOURCE STRUCTURE] The first structure adjust patch is pushed

by Ken Liu

Hi, As the first commit of 'source_structure' document is merged, here is the first patch to follow the document: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4315 The patch looks big, even it just adjusts the content inside 'secure_fw'. To make the related sources can pass the building, some files out of the 'secure_fw' need to be changed. The goal of merging is ASAP so that we won't block upcoming features. Please provide the feedback about potential USAGE problem you may meet. As the patch is big, it won't be applicable to make THIS patch perfect to meet all the requirements defined in the document, a series of upcoming patches would come as amending. Also if there are suggestions about the structure document, please write to the mailing list and put discussion in this task: https://developer.trustedfirmware.org/T751 The rendered structure document: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/252/artifact/bui… BR /Ken

5 years, 5 months

1
0
0 0

DSP instructions and FPU use

by Cindy Chaumont

Hello, I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image). About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file). Is there a reason for that? Maybe some performance reasons? About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions? Thank you in advance for the answer, Best regards, Cindy

5 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M