- TF-M - lists.trustedfirmware.org

Re: [TF-M] TF-M URLs update for code and Gerrit review

by Thomas Törnblom

Thanks Anton, that explains things. However now I get some other issues: --- PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git HEAD:refs/for/master Enumerating objects: 208, done. Counting objects: 100% (207/207), done. Delta compression using up to 4 threads Compressing objects: 100% (131/131), done. Writing objects: 100% (135/135), 16.94 KiB | 1.06 MiB/s, done. Total 135 (delta 97), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (97/97) remote: Processing changes: refs: 1, done To ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git ! [remote rejected] HEAD -> refs/for/master (I00fb896d2005eb9e64e5a6869e3d6e1d814d43a7 has duplicates) error: failed to push some refs to 'ssh://review.trustedfirmware.org/TF-M/trusted-firmware-m.git' --- Thomas Den 2020-06-08 kl. 13:43, skrev Anton Komlev via TF-M: > > Hello > > TF-M code moved to the new location recently with a redirection link > from the original URL – for compatibility purpose. > > Unfortunately, Gerrit got confused with two namespaces and several > patches got messed up last week. To prevent it from happen again, the > old TF-M location marked as read-only mirror. > > Please use new TF-M URL for your pushing your commits: > > ssh://<user-name>@review.trustedfirmware.org:29418/TF-M/trusted-firmware-m > > New repo URL: > > https://review.trustedfirmware.org/TF-M/trusted-firmware-m > > Thanks, > > Anton > > -- *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, 10 months

1
0
0 0

Re: [TF-M] Gerrit issues

by Thomas Törnblom

Is this perhaps related to the .gitreview and/or new repo location changes that appears to have been merged after my last push on Friday? If so, how to I fix this in my local repo? Thomas Den 2020-06-08 kl. 11:53, skrev Thomas Törnblom via TF-M: > Is there a problem pushing patches currently, or is there something > I've missed? > > I was able to push a patch on Friday, but today I get errors just > trying to push after a rebase with no changes: > --- > PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push > ssh://review.trustedfirmware.org:29418/trusted-firmware-m.git > HEAD:refs/for/master > Enumerating objects: 22731, done. > Counting objects: 100% (22731/22731), done. > Delta compression using up to 4 threads > Compressing objects: 100% (7566/7566), done. > Writing objects: 100% (22731/22731), 11.22 MiB | 6.64 MiB/s, done. > Total 22731 (delta 15732), reused 21321 (delta 14653) > remote: Resolving deltas: 100% (15732/15732) > remote: Processing changes: refs: 1, done > To ssh://review.trustedfirmware.org:29418/trusted-firmware-m.git > ! [remote rejected] HEAD -> refs/for/master (prohibited by Gerrit: > project state does not permit write) > error: failed to push some refs to > 'ssh://review.trustedfirmware.org:29418/trusted-firmware-m.git' > --- > > 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, 10 months

1
0
0 0

TF-M URLs update for code and Gerrit review

by Anton Komlev

Hello TF-M code moved to the new location recently with a redirection link from the original URL - for compatibility purpose. Unfortunately, Gerrit got confused with two namespaces and several patches got messed up last week. To prevent it from happen again, the old TF-M location marked as read-only mirror. Please use new TF-M URL for your pushing your commits: ssh://<user-name>@review.trustedfirmware.org:29418/TF-M/trusted-firmware-m New repo URL: https://review.trustedfirmware.org/TF-M/trusted-firmware-m Thanks, Anton

4 years, 10 months

1
0
0 0

Gerrit issues

by Thomas Törnblom

Is there a problem pushing patches currently, or is there something I've missed? I was able to push a patch on Friday, but today I get errors just trying to push after a rebase with no changes: --- PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m> git push ssh://review.trustedfirmware.org:29418/trusted-firmware-m.git HEAD:refs/for/master Enumerating objects: 22731, done. Counting objects: 100% (22731/22731), done. Delta compression using up to 4 threads Compressing objects: 100% (7566/7566), done. Writing objects: 100% (22731/22731), 11.22 MiB | 6.64 MiB/s, done. Total 22731 (delta 15732), reused 21321 (delta 14653) remote: Resolving deltas: 100% (15732/15732) remote: Processing changes: refs: 1, done To ssh://review.trustedfirmware.org:29418/trusted-firmware-m.git ! [remote rejected] HEAD -> refs/for/master (prohibited by Gerrit: project state does not permit write) error: failed to push some refs to 'ssh://review.trustedfirmware.org:29418/trusted-firmware-m.git' --- 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, 10 months

1
0
0 0

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

by David Vincze

Hi, I also would like to give a brief update on the status of the ongoing MCUboot alignment work. David V From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: 05 June 2020 11:23 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - June 11 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<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: 03 June 2020 21:21 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M 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

4 years, 10 months

1
0
0 0

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

4 years, 10 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

4 years, 10 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

4 years, 10 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

4 years, 10 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

4 years, 10 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

4 years, 10 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

4 years, 10 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

4 years, 10 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

4 years, 10 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

4 years, 10 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

4 years, 10 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

4 years, 10 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

4 years, 11 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

4 years, 11 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

4 years, 11 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

4 years, 11 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

4 years, 11 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

4 years, 11 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

4 years, 11 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

4 years, 11 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

4 years, 11 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

4 years, 11 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

4 years, 11 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

4 years, 11 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

4 years, 11 months

1
0
0 0

TF-M Profile Small patches merged

by David Hu

Hi all, TF-M Profile Small patches are merged in TF-M master branch. Thanks a lot for all your review, comments and support. I'd appreciate it if you could feedback and share ideas while enabling Profile Small in your actual use cases. If there is any issue, please feel free to let us know. Thank you. The next step will bring in symmetric key algorithm based Initial Attestation and then Profile Small can have a full set of features. Best regards, Hu Ziji

4 years, 11 months

1
0
0 0

Correction - MMIO region is not sharable between partitions

by Ken Liu

Hi, In the tech forum I mentioned a potential way of sharing MMIO regions - this is not correct. Double checked the PSA FF and it is defined explicitly in the spec page 43: "A Secure Partition always has exclusive access to an MMIO region. Secure Partitions are not allowed to share MMIO regions with other Secure Partitions and MMIO regions are not allowed to overlap." Sorry for the confusion. BR /Ken

4 years, 11 months

1
0
0 0

Re: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM

by Jonatan Antoni

Hi Gyorgy, Ken, Let me add one statement to Gyorgy's > It became a de-facto standard and most compilers support it. Compilers not yet supported can be easily added, if required. Cheers, Jonatan From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 27 May 2020 10:45 To: Ken Liu <Ken.Liu(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi Ken, One of the most well working part of CMSIS is the compiler abstraction layer: * It does wat is needed. * Most functionality can not be coded in a different way (i.e. intrinsics). * It became a de-facto standard and most compilers support it. What are the benefits driving re-implementation? /George 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: 27 May 2020 02:39 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] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi Jamie, At the current stage: * The CMSIS headers dependency has been moved into HAL, the SPM native code would not rely on specific system provided definitions. * These usages are quite TF-M specific and small so there is less significance to upstream back, we can revisit if need to do this after extended the header content - but this extending is out of original design expectation. BR /Ken From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Tuesday, May 26, 2020 10:52 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: [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi Ken, Many similar abstractions for compiler C language extensions are provided by cmsis_compiler.h, already copied into the TF-M code base. If it does not meet all of our needs, should we consider proposing improvements to the upstream CMSIS project? Kind regards, Jamie 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: 25 May 2020 05:02 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] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi, We created a proposal to define a minimal set of compiler specific-definitions for SPM. The reason is to avoid many #ifdef inside SPM code. Only limited definitions are defined. Platform sources need to use platform defined headers for these definitions, such as CMSIS headers. Special usage such as 'weak' or 'noreturn' are forbidden inside SPM. Please put comments for this change: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4211 Or reply here. This is just an example patch, the follow up would apply this defined headers to all SPM sources. Thanks /Ken

4 years, 11 months

1
0
0 0

Re: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM

by Gyorgy Szing

Hi Ken, One of the most well working part of CMSIS is the compiler abstraction layer: * It does wat is needed. * Most functionality can not be coded in a different way (i.e. intrinsics). * It became a de-facto standard and most compilers support it. What are the benefits driving re-implementation? /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 27 May 2020 02:39 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi Jamie, At the current stage: * The CMSIS headers dependency has been moved into HAL, the SPM native code would not rely on specific system provided definitions. * These usages are quite TF-M specific and small so there is less significance to upstream back, we can revisit if need to do this after extended the header content - but this extending is out of original design expectation. BR /Ken From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Tuesday, May 26, 2020 10:52 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: [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi Ken, Many similar abstractions for compiler C language extensions are provided by cmsis_compiler.h, already copied into the TF-M code base. If it does not meet all of our needs, should we consider proposing improvements to the upstream CMSIS project? Kind regards, Jamie 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: 25 May 2020 05:02 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] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi, We created a proposal to define a minimal set of compiler specific-definitions for SPM. The reason is to avoid many #ifdef inside SPM code. Only limited definitions are defined. Platform sources need to use platform defined headers for these definitions, such as CMSIS headers. Special usage such as 'weak' or 'noreturn' are forbidden inside SPM. Please put comments for this change: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4211 Or reply here. This is just an example patch, the follow up would apply this defined headers to all SPM sources. Thanks /Ken

4 years, 11 months

2
1
0 0

Re: [TF-M] Pre-provisioned keys

by Tamas Ban

Hi Brian, The pre-provisioned keys are highly platform dependent. TF-M just provide an API to access them, but currently we have no standard/general solution to storing them. There was question a few weeks ago related to same topic. I just copied Shebu's past answer here: "Provisioning was added as a future roadmap item in anticipation of a PSA Provisioning Specification. The Specification (Factory or application specific) hasn't happened so far. There is no active work ongoing in TF-M around provisioning. TF-M using provisioned keys in CC-312 on MuscaB1 platform is available as an example. See details here<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> under CC312 heading. In TrustedFirmware TSC, provisioning has been a discussion topic sometime back. Search for provisioning in the minutes below. https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md is an RFC that Kevin prepared during those discussions for TF-M devices to use certificate chain. " I hope this helps! Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 27 May 2020 03:41 To: tf-m(a)lists.trustedfirmware.org; Quach, Brian <brian(a)ti.com> Cc: nd <nd(a)arm.com> Subject: [TF-M] FW: Pre-provisioned keys Hi Folks, Brian got one question about pre-provisioned keys, anyone could reply? Hi Brian, you can subscribe the mailing list here: https://lists.trustedfirmware.org/mailman/listinfo/tf-m Thanks. /Ken From: Quach, Brian <brian(a)ti.com<mailto:brian@ti.com>> Sent: Wednesday, May 27, 2020 6:36 AM Subject: Pre-provisioned keys Hi Ken, Does TF-M have a plan for storing and accessing persistent keys (such as HUK) installed to flash at the factory prior to provisioning of the device? I had seen these as being stored outside of ITS flash in some compile time defined location and being read-only. Regards, Brian

4 years, 11 months

1
0
0 0

FW: Pre-provisioned keys

by Ken Liu

Hi Folks, Brian got one question about pre-provisioned keys, anyone could reply? Hi Brian, you can subscribe the mailing list here: https://lists.trustedfirmware.org/mailman/listinfo/tf-m Thanks. /Ken From: Quach, Brian <brian(a)ti.com> Sent: Wednesday, May 27, 2020 6:36 AM Subject: Pre-provisioned keys Hi Ken, Does TF-M have a plan for storing and accessing persistent keys (such as HUK) installed to flash at the factory prior to provisioning of the device? I had seen these as being stored outside of ITS flash in some compile time defined location and being read-only. Regards, Brian

4 years, 11 months

1
0
0 0

Re: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM

by Jamie Fox

Hi Ken, Many similar abstractions for compiler C language extensions are provided by cmsis_compiler.h, already copied into the TF-M code base. If it does not meet all of our needs, should we consider proposing improvements to the upstream CMSIS project? Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 25 May 2020 05:02 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi, We created a proposal to define a minimal set of compiler specific-definitions for SPM. The reason is to avoid many #ifdef inside SPM code. Only limited definitions are defined. Platform sources need to use platform defined headers for these definitions, such as CMSIS headers. Special usage such as 'weak' or 'noreturn' are forbidden inside SPM. Please put comments for this change: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4211 Or reply here. This is just an example patch, the follow up would apply this defined headers to all SPM sources. Thanks /Ken

4 years, 11 months

2
1
0 0

Re: [TF-M] TF-M Technical Forum call - May 28

by Edison Ai

Hi Anton, I want to give an introduction about the HAL for TF-M core, about 30 mins. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, May 19, 2020 9:46 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - May 28 Hello, The next Technical Forum is planned on Thursday, May 28 at 6:00-7:00 UTC (Asia 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) Wednesday, 27 May 2020, 23:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 28 May 2020, 01: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, 28 May 2020, 07: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, 28 May 2020, 14:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 28 May 2020, 06:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200528T0600> Best regards, Anton Komlev

4 years, 11 months

1
0
0 0

by Ken Liu

Hi, We created a proposal to define a minimal set of compiler specific-definitions for SPM. The reason is to avoid many #ifdef inside SPM code. Only limited definitions are defined. Platform sources need to use platform defined headers for these definitions, such as CMSIS headers. Special usage such as 'weak' or 'noreturn' are forbidden inside SPM. Please put comments for this change: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4211 Or reply here. This is just an example patch, the follow up would apply this defined headers to all SPM sources. Thanks /Ken

4 years, 11 months

1
0
0 0

Simplify the veneers of library model

by Mingyang Sun

Hi all, In the current implementation, every secure function has an associated veneer function. Therefore, there are so many veneer functions in ‘tfm_veneers.c’, which have a similar prototype. This would lead to: * Waste of the veneer and secure function size – these APIs have a similar prototype, and they have unified NS dispatcher already. * More secure functions lead to more veneers and potential re-configuration of the non-secure callable area. This patch tries to unify the service entry so that: * Similar function codes do not need to be duplicated. * Keeping almost the same performance. This is also an experiment patch to start the journey to the SFN model Andrew proposed. Let’s see the feedbacks and decide what to do in the next step. https://review.trustedfirmware.org/c/trusted-firmware-m/+/4115 Please do feedback, especially the library model users – please check what kinds of the inconvenience it brings so that we can discuss the correct shape. Here are some details in the patch: Prototype of the unified veneer function: psa_status_t tfm_sfc_call(uint32_t ctrl, psa_invec *in_vec, psa_outvec *out_vec); where: the uint32_t type parameter ‘ctrl’ is a pack of parameters - psa invec length, psa outvec length, and function identifier. [8 bits for inlen][8 bits for outlen][16 bits for function identifier] This is to avoid the condition that 5 parameters will cause re-wrapping of parameters. Time cost and code size measurement: github-tracking Use the unified veneer cost of a veneer call is 1264 cost of an interrupt is 941 veneer used 832B, region size 832B, 100% cost of a veneer call is 1274 cost of an interrupt is 941 veneer used 64B, region size 832B, 7.69% Thanks, Mingyang

4 years, 11 months

1
0
0 0

Re: [TF-M] TF-M and provisioning

by Shebu Varghese Kuriakose

Hi Gernot, Provisioning was added as a future roadmap item in anticipation of a PSA Provisioning Specification. The Specification (Factory or application specific) hasn't happened so far. There is no active work ongoing in TF-M around provisioning. TF-M using provisioned keys in CC-312 on MuscaB1 platform is available as an example. See details here<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> under CC312 heading. In TrustedFirmware TSC, provisioning has been a discussion topic sometime back. Search for provisioning in the minutes below. https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md is an RFC that Kevin prepared during those discussions for TF-M devices to use certificate chain. Regards, Shebu https://lists.trustedfirmware.org/pipermail/tsc/2019-September/000044.html https://lists.trustedfirmware.org/pipermail/tsc/2019-October/000048.html https://lists.trustedfirmware.org/pipermail/tsc/2019-November/000052.html https://lists.trustedfirmware.org/pipermail/tsc/2019-December/000068.html https://lists.trustedfirmware.org/pipermail/tsc/2020-January/000072.html https://lists.trustedfirmware.org/pipermail/tsc/2020-February/000076.html -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gernot Kvas via TF-M Sent: Tuesday, May 19, 2020 10:03 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M and provisioning Hello, I would like to understand the background behind roadmap item "Provisioning" that is mentioned here [1] (Slide 31) and here [2]. What provisioning functionality would we be talking here, is it provisioning as in "RoT provisioning", so more towards manufacturing as defined in the PSA security lifecycle, or provisioning when the device is in state "Secured", so more towards application specific-data? I would assume the latter, but couldn't find any more information on this subject. Any pointers would be highly appreciated. Thanks for your help & kind regards, Gernot [1] https://static.linaro.org/connect/san19/presentations/san19-203.pdf [2] https://developer.trustedfirmware.org/w/tf_m/planning/ -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

1
0
0 0

TF-M and provisioning

by Gernot Kvas

Hello, I would like to understand the background behind roadmap item "Provisioning" that is mentioned here [1] (Slide 31) and here [2]. What provisioning functionality would we be talking here, is it provisioning as in "RoT provisioning", so more towards manufacturing as defined in the PSA security lifecycle, or provisioning when the device is in state "Secured", so more towards application specific-data? I would assume the latter, but couldn't find any more information on this subject. Any pointers would be highly appreciated. Thanks for your help & kind regards, Gernot [1] https://static.linaro.org/connect/san19/presentations/san19-203.pdf [2] https://developer.trustedfirmware.org/w/tf_m/planning/

4 years, 11 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - May 14

by Anton Komlev

Ups, please ignore this invitation with outdated subject. I have sent a better one. Sorry for confusion. Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 19 May 2020 13:58 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M Technical Forum call - May 14 Hello, The next Technical Forum is planned on Thursday, May 28 at 6:00-7:00 UTC (Asia 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) Wednesday, 27 May 2020, 23:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 28 May 2020, 01: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, 28 May 2020, 07: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, 28 May 2020, 14:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 28 May 2020, 06:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200528T0600> Best regards, Anton Komlev

4 years, 11 months

1
0
0 0

TF-M Technical Forum call - May 28

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, May 28 at 6:00-7:00 UTC (Asia 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) Wednesday, 27 May 2020, 23:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 28 May 2020, 01: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, 28 May 2020, 07: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, 28 May 2020, 14:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 28 May 2020, 06:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200528T0600> Best regards, Anton Komlev

4 years, 11 months

1
0
0 0

TF-M Technical Forum call - May 14

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, May 28 at 6:00-7:00 UTC (Asia 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) Wednesday, 27 May 2020, 23:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 28 May 2020, 01: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, 28 May 2020, 07: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, 28 May 2020, 14:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 28 May 2020, 06:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200528T0600> Best regards, Anton Komlev

4 years, 11 months

1
0
0 0

Re: [TF-M] PSA documentation page

by Ken Liu

Now we linked the home page (https://developer.arm.com/architectures/security-architectures/platform-sec…) of PSA in the readme (https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…), are you proposing to update to this documentation link? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M Sent: Monday, May 18, 2020 6:12 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA documentation page For anyone who is interested in a more comprehensive list of the PSA documents, the following page is now available on developer.arm.com that lists the documents, the latest specification versions and their current quality status. https://developer.arm.com/architectures/security-architectures/platform-sec… Best, Adrian

4 years, 11 months

1
0
0 0

[RFC] Compiler-specific configurations and architecture registers

by Summer Qin

Hi, Even the ongoing HAL design abstracts all platform-specific operations, there are still some operations that need to be performed directly in TF-M, such as architecture-related operations. These operations are common for all platforms, such as: * generic assembler code for AAPCS based context management. * assign attributes to specific functions. These operations rely on compiler and architecture much instead of the platform. So, define a CORE-specific compiler configuration header file would be a straight requirement. With these unified headers, writing the architecture-specific code would be much safer because it won't involve hardcode compiler related changes. The minimal set of mandatory architecture registers is also planned to be defined. Here send out a mail to collect for the feedbacks - is it worthy of doing this to decouple the architecture from the platform, or we can just re-use the platform provided headers? Any comments are welcome:) Best Regards, Summer

4 years, 11 months

1
0
0 0

PSA documentation page

by Adrian Shaw

For anyone who is interested in a more comprehensive list of the PSA documents, the following page is now available on developer.arm.com that lists the documents, the latest specification versions and their current quality status. https://developer.arm.com/architectures/security-architectures/platform-sec… Best, Adrian

4 years, 11 months

1
0
0 0

Proposal to add sub-folders to collect documents under design_documents folder

by David Hu

Hi all, I'd like to propose to add sub-folders under docs/design_documents to collect the documents on the same topic. Currently, there are already 21 documents in total under docs/design_documents and the number may grow rapidly. It can be more clear if we can organize the documents on the same topic into a dedicated sub-folder under docs/design_documents. Please help review the patch set https://review.trustedfirmware.org/q/topic:%22design-doc-subdir%22+(status:… if the proposal sound interesting. I move dual-cpu and TF-M Profiles related documents to their dedicated folder respectively in the patches. Any comment is welcome! In current patches, the html pages are still put in the same level during Sphinx build. It is because design documents are grouped by document status, instead of document hierarchy. The html pages can be further organized as well if we switch to group html according to folder structures. Best regards, Hu Ziji

4 years, 11 months

1
0
0 0

Ask for final review of symmetric based initial attestation design

by David Hu

Hi all, May I ask for a final round of review on symmetric initial attestation design document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3898? The document has been reviewed for a long time and received many valuable comments. Thanks a lot. If there is no further critical comment, I'd like to merge this design this Friday. Best regards, Hu Ziji

4 years, 11 months

1
0
0 0

[RFC] [Source Structure] Design document is availiable.

by Ken Liu

Hi, There is an upcoming source structure adjustment for TF-M. The basic idea is to make the structure simple and easy to be understood by users. The significant change would be a long term goal so no worry. In the beginning, there would be changes in core and platform to align with HAL changes. Please help to put comments on the design documents - after aligned, this document would be a user guide document to describe the source structure of TF-M. The patch is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/4112 And the issue link: https://developer.trustedfirmware.org/T751 Feel free to put any comments or ask questions. Thanks. /Ken

4 years, 11 months

1
0
0 0

IRQ testing tool available for review

by Mate Toth-Pal

Hi All, The IRQ testing tool proposed for TF-M earlier, and presented in one of the TF-M tech forum is available for code review: https://review.trustedfirmware.org/c/trusted-firmware-m/+/4078/1 https://review.trustedfirmware.org/c/trusted-firmware-m/+/4079/1 The presentation can be viewed here: https://zoom.us/rec/share/3epSNYjX519Oeony5HH8WIgqXb7peaa82iYf_vZYmBuPbFktC… (Extended) Slides: https://www.trustedfirmware.org/docs/Automated_testing_of_interrupt_handlin… Please give feedback in gerrit review comments. Thanks, Mate

4 years, 11 months

1
0
0 0

Re: [TF-M] Attestation: is there an usage example for that somewhere

by Adrian Shaw

Hi Reinhard, Attestation is implemented in TF-M. There is a whitepaper here explaining attestation use cases and usage models https://www.psacertified.org/app/uploads/2020/02/PSA-Certified-Entity-Attes… The API is documented in the specification ARM IHI 0085, which you can find here https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Im… Best, Adrian On 14 May 2020, at 15:55, Reinhard Keil via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Is Attestation already implemented? Is there somewhere information on how Attestation is used. I’m looking for user oriented information. Thanks for your help. Reinhard -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 11 months

1
0
0 0

Attestation: is there an usage example for that somewhere

by Reinhard Keil

Is Attestation already implemented? Is there somewhere information on how Attestation is used. I'm looking for user oriented information. Thanks for your help. Reinhard

4 years, 11 months

1
0
0 0

Re: [TF-M] Boot seed in TFM Attestation tests

by Andrej Butok

Hi Tamas, The patch has eliminated the test fail. Thank you, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Thursday, May 14, 2020 2:32 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Boot seed in TFM Attestation tests Hi Andrej, The value of boot_seed is compared against a hard coded value. This behaviour can be turned off in test/suites/attestation/attest_token_test_values.h. Then only the presence of boot_seed claim will be checked but its value not. Could you test this patch: diff --git a/test/suites/attestation/attest_token_test_values.h b/test/suites/attestation/attest_token_test_values.h index 5910524..fe2b9d4 100644 --- a/test/suites/attestation/attest_token_test_values.h +++ b/test/suites/attestation/attest_token_test_values.h @@ -110,6 +110,8 @@ /* A 32 byte mostly random value. Binary. * platform/ext/common/template/attest_hal.c */ +#define TOKEN_TEST_VALUE_BOOT_SEED NULL_Q_USEFUL_BUF_C +/* #define TOKEN_TEST_VALUE_BOOT_SEED \ (struct q_useful_buf_c) {\ (uint8_t[]){ \ @@ -120,6 +122,7 @@ },\ 32\ } +*/ #define TOKEN_TEST_REQUIRE_BOOT_SEED true /* Mandatory claim */ /* A text string in EAN 13 format Tamas 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: 14 May 2020 12:06 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Boot seed in TFM Attestation tests Hello, Using a real boot seed instead of the dummy one is causing a Attestation Service regression fail. The log: Running Test Suite Initial Attestation Service non-secure interface tests(TFM_ATTEST_TEST_2XXX)... > Executing 'TFM_ATTEST_TEST_2004' Description: 'ECDSA signature test of attest token' decode_test_normal_sig() returned: -55 Attest token decode_test_normal_sig() has failed (Failed at ../../../../../../middleware/tfm/test/suites/attestation/non_secure/attestation_ns_interface_testsuite.c:136) TEST FAILED! Is it know issue? Probably, it's better to use a real boot seed by the Attestation tests, returned by tfm_plat_get_initial_attest_key()? Thank you, Andrej Butok

4 years, 11 months

2
1
0 0

TF-M repository restructure

by Anton Komlev

Hello, Let me announce the changes in TF-M project repository structure. To allow project grow up in a more organized way the existing codebase will be split on multiple repositories and placed under TF-M folder. This is the similar structure as all other projects have in git.trustedfirmware.org<https://git.trustedfirmware.org>. This weekend TF-M git repository will be moved from https://git.trustedfirmware.org/trusted-firmware-m.git to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git The original URL will be supported for some time (as a link to the new one) giving time for adjustment. Current plan is to keep the redirection for 6 months but let me know please, if it makes any conflict and another depreciation period is better. Best regards, Anton Komlev

4 years, 11 months

1
0
0 0

Re: [TF-M] Boot seed in TFM Attestation tests

by Tamas Ban

Hi Andrej, The value of boot_seed is compared against a hard coded value. This behaviour can be turned off in test/suites/attestation/attest_token_test_values.h. Then only the presence of boot_seed claim will be checked but its value not. Could you test this patch: diff --git a/test/suites/attestation/attest_token_test_values.h b/test/suites/attestation/attest_token_test_values.h index 5910524..fe2b9d4 100644 --- a/test/suites/attestation/attest_token_test_values.h +++ b/test/suites/attestation/attest_token_test_values.h @@ -110,6 +110,8 @@ /* A 32 byte mostly random value. Binary. * platform/ext/common/template/attest_hal.c */ +#define TOKEN_TEST_VALUE_BOOT_SEED NULL_Q_USEFUL_BUF_C +/* #define TOKEN_TEST_VALUE_BOOT_SEED \ (struct q_useful_buf_c) {\ (uint8_t[]){ \ @@ -120,6 +122,7 @@ },\ 32\ } +*/ #define TOKEN_TEST_REQUIRE_BOOT_SEED true /* Mandatory claim */ /* A text string in EAN 13 format Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 14 May 2020 12:06 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Boot seed in TFM Attestation tests Hello, Using a real boot seed instead of the dummy one is causing a Attestation Service regression fail. The log: Running Test Suite Initial Attestation Service non-secure interface tests(TFM_ATTEST_TEST_2XXX)... > Executing 'TFM_ATTEST_TEST_2004' Description: 'ECDSA signature test of attest token' decode_test_normal_sig() returned: -55 Attest token decode_test_normal_sig() has failed (Failed at ../../../../../../middleware/tfm/test/suites/attestation/non_secure/attestation_ns_interface_testsuite.c:136) TEST FAILED! Is it know issue? Probably, it's better to use a real boot seed by the Attestation tests, returned by tfm_plat_get_initial_attest_key()? Thank you, Andrej Butok

4 years, 11 months

1
0
0 0

Boot seed in TFM Attestation tests

by Andrej Butok

Hello, Using a real boot seed instead of the dummy one is causing a Attestation Service regression fail. The log: Running Test Suite Initial Attestation Service non-secure interface tests(TFM_ATTEST_TEST_2XXX)... > Executing 'TFM_ATTEST_TEST_2004' Description: 'ECDSA signature test of attest token' decode_test_normal_sig() returned: -55 Attest token decode_test_normal_sig() has failed (Failed at ../../../../../../middleware/tfm/test/suites/attestation/non_secure/attestation_ns_interface_testsuite.c:136) TEST FAILED! Is it know issue? Probably, it's better to use a real boot seed by the Attestation tests, returned by tfm_plat_get_initial_attest_key()? Thank you, Andrej Butok

4 years, 11 months

1
0
0 0

Re: [TF-M] Query on persistent keys Crypto API

by Soby Mathew

Hi Kevin > Presumably this positions the merged change request around 1.0 beta 3, just to know where we stand with the API documentation versus implementation in TF-M? Yes, you are right, the Crypto service as implemented in TF-M positions it very close to 1.0 beta 3 API specification. There is still some unimplemented functionality and some differences in error code with respect to the Beta3 specification as reported by the compliance test suite here : https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/docs/t… > Presumably this migration to ID based accesses (versus handles) is still a work in progress, with a goal of perhaps being complete for 1.1? Yes, TF-M depends on mbedcrypto to provide the necessary functionality. This is work in progress and hopefully available towards Q3 timeframe. > If I comment out the psa_open_key call, I CAN access the public key in the next function, but only because I have a reference to the handle from when we first persisted the key, but I wouldn't have that handle in the real world if I was accessing a previously created key, and it seems we can't access persisted keys via ID yet, only handles, unless I'm missing something (perhaps obvious)? Hopefully the solution suggested by Sherry is good enough for you to progress although your code will need to migrate to the API as specified in v1.0 at sometime in the future when TF-M implements the same. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 13 May 2020 12:25 To: Sherry Zhang <Sherry.Zhang2(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Query on persistent keys Crypto API Hi Sherry, Thanks for the quick response. The following sequence, explicitly closing the key after creation, seems to allow me to use psa_open_key, thank you: /* Import the private key, creating the persistent key on success */ psa_import_key(&key_attributes, key_data, key_len, &key_handle); /* Close the key to free up a volatile slot. */ psa_close_key(key_handle); /* Now try to re-open the persisted key based on the key ID. */ psa_open_key(key_id, &key_handle); Best regards, Kevin On Wed, 13 May 2020 at 12:48, Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> wrote: Hi Kevin, Yes, you are right. The persistent key management described in PSA Cryptograhphy version 1.0 is not supported yet. It still follows the version 1.0 beta3 “key management”. I also met the “INSUFFICIENT_MEMORY” issue when I am implementing the PSA based PKCS#11 shim layer. In my side, it is caused by multiple calling psa_open_key while the key is still open. Each persistent key is saved only once in non- volatile area. But each time you open a key with the key handle, a new volatile area is used. In your code, psa_open_key is called directly after psa_import_key. So in this case, an additional volatile area is taken. The default volatile area number is 16. I suggestion you check whether similar case happen in your code(calling psa_open_key while the key is in open). After provisioning, call psa_close_key to close the key. Then the volatile area is freed. Then to get the key handle later, you can call the psa_open_key directly. Hope it can help you! Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Wednesday, May 13, 2020 5:47 PM To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Query on persistent keys Crypto API Hi, Support for generating and working with persistent keys was recently merged into TF-M in the following change request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252/8 This corresponds to section 3.2.2 (Persistent keys) of the PSA Cryptography API 1.0 (dated 19/02/2020), although there seems to be some delay in implementing the functionality described in the API document. Page 209 ("Changes between 1.0 beta 3 and 1.0.0") states: "Removed psa_open_key and psa_close_key", but these functions are both present in the repo and seem to be used in the tests here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry… Presumably this positions the merged change request around 1.0 beta 3, just to know where we stand with the API documentation versus implementation in TF-M? Since this is a very useful feature in real world applications, I was working on a sample application in Zephyr demonstrating how it might be used during device provisioning, and I was hoping to better understand the differences between the implementation in TF-M today and the 1.0 API document, specifically around KEY IDs versus key handle based access? The 1.0 API documentation, for example, describes: psa_status_t psa_export_public_key(psa_key_id_t key, uint8_t * data, size_t data_size, size_t * data_length); But TF-M implements this add: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… psa_status_t psa_export_public_key(psa_key_handle_t handle, uint8_t *data, size_t data_size, size_t *data_length); Presumably this migration to ID based accesses (versus handles) is still a work in progress, with a goal of perhaps being complete for 1.1? Should I still be calling psa_open_key in the interim, for example? Some examples like the AES + PKCS#7 test case here use that: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry… However, when I try to use psa_open_key when working with PSA_ECC_CURVE_SECP256R1, I get an INSUFFICIENT_MEMORY error, and I'm not sure how to get the psa_key_handle_t for subsequent operations like reading the key back. I've posted the WIP code that fails trying to open the key here: https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05#file-… If I comment out the psa_open_key call, I CAN access the public key in the next function, but only because I have a reference to the handle from when we first persisted the key, but I wouldn't have that handle in the real world if I was accessing a previously created key, and it seems we can't access persisted keys via ID yet, only handles, unless I'm missing something (perhaps obvious)? Best regards, Kevin

4 years, 11 months

1
0
0 0

Re: [TF-M] BL2 scatter file issue

by Tamas Ban

Hi Mark, Thank you, I think your observation is right. I have opened the following ticket to fix: https://developer.trustedfirmware.org/T749 Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 13 May 2020 17:13 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] BL2 scatter file issue Hi, I think there is an error in the usual BL2 scatter file, for example in platform<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform>/ext<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext>/target<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/musca_b1<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/Device<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/Source<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/armclang<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/musca_bl2.sct<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…> The maximum size of the region ER_DATA is set to BL2_DATA_SIZE which is usually equals to the size of the available RAM. But not just the ER_DATA region have to be placed into RAM but also the BOOT_DATA, the heap and the MSP stack. In addition if the TFM_MULTI_CORE_TOPOLOGY macro is set then the BOOT_DATA is not placed at the start of the RAM in TF-M but after unprivileged data. So I would recommend to use the same check like in tfm_common_s.sct and adjust BOOT_DATA start: --- a/platform/ext/target/musca_b1/Device/Source/armclang/musca_bl2.sct +++ b/platform/ext/target/musca_b1/Device/Source/armclang/musca_bl2.sct @@ -24,10 +24,10 @@ LR_CODE BL2_CODE_START { * (+RO) } - TFM_SHARED_DATA BL2_DATA_START ALIGN 32 EMPTY BOOT_TFM_SHARED_DATA_SIZE { + TFM_SHARED_DATA BOOT_TFM_SHARED_DATA_BASE ALIGN 32 EMPTY BOOT_TFM_SHARED_DATA_SIZE { } - ER_DATA +0 BL2_DATA_SIZE { + ER_DATA +0 { * (+ZI +RW) } @@ -37,4 +37,15 @@ LR_CODE BL2_CODE_START { ARM_LIB_HEAP +0 ALIGN 8 EMPTY BL2_HEAP_SIZE { } + + /* This empty, zero long execution region is here to mark the limit address + * of the last execution region that is allocated in SRAM. + */ + SRAM_WATERMARK +0 EMPTY 0x0 { + } + + /* Make sure that the sections allocated in the SRAM does not exceed the + * size of the SRAM available. + */ + ScatterAssert(ImageLimit(SRAM_WATERMARK) <= BL2_DATA_START + BL2_DATA_SIZE) } What are your thoughts? Best regards, Mark

4 years, 11 months

1
0
0 0

BL2 scatter file issue

by Mark Horvath

Hi, I think there is an error in the usual BL2 scatter file, for example in platform<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform>/ext<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext>/target<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/musca_b1<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/Device<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/Source<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/armclang<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/musca_bl2.sct<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…> The maximum size of the region ER_DATA is set to BL2_DATA_SIZE which is usually equals to the size of the available RAM. But not just the ER_DATA region have to be placed into RAM but also the BOOT_DATA, the heap and the MSP stack. In addition if the TFM_MULTI_CORE_TOPOLOGY macro is set then the BOOT_DATA is not placed at the start of the RAM in TF-M but after unprivileged data. So I would recommend to use the same check like in tfm_common_s.sct and adjust BOOT_DATA start: --- a/platform/ext/target/musca_b1/Device/Source/armclang/musca_bl2.sct +++ b/platform/ext/target/musca_b1/Device/Source/armclang/musca_bl2.sct @@ -24,10 +24,10 @@ LR_CODE BL2_CODE_START { * (+RO) } - TFM_SHARED_DATA BL2_DATA_START ALIGN 32 EMPTY BOOT_TFM_SHARED_DATA_SIZE { + TFM_SHARED_DATA BOOT_TFM_SHARED_DATA_BASE ALIGN 32 EMPTY BOOT_TFM_SHARED_DATA_SIZE { } - ER_DATA +0 BL2_DATA_SIZE { + ER_DATA +0 { * (+ZI +RW) } @@ -37,4 +37,15 @@ LR_CODE BL2_CODE_START { ARM_LIB_HEAP +0 ALIGN 8 EMPTY BL2_HEAP_SIZE { } + + /* This empty, zero long execution region is here to mark the limit address + * of the last execution region that is allocated in SRAM. + */ + SRAM_WATERMARK +0 EMPTY 0x0 { + } + + /* Make sure that the sections allocated in the SRAM does not exceed the + * size of the SRAM available. + */ + ScatterAssert(ImageLimit(SRAM_WATERMARK) <= BL2_DATA_START + BL2_DATA_SIZE) } What are your thoughts? Best regards, Mark

4 years, 11 months

1
0
0 0

Re: [TF-M] Query on persistent keys Crypto API

by Sherry Zhang

Hi Kevin, Yes, you are right. The persistent key management described in PSA Cryptograhphy version 1.0 is not supported yet. It still follows the version 1.0 beta3 “key management”. I also met the “INSUFFICIENT_MEMORY” issue when I am implementing the PSA based PKCS#11 shim layer. In my side, it is caused by multiple calling psa_open_key while the key is still open. Each persistent key is saved only once in non- volatile area. But each time you open a key with the key handle, a new volatile area is used. In your code, psa_open_key is called directly after psa_import_key. So in this case, an additional volatile area is taken. The default volatile area number is 16. I suggestion you check whether similar case happen in your code(calling psa_open_key while the key is in open). After provisioning, call psa_close_key to close the key. Then the volatile area is freed. Then to get the key handle later, you can call the psa_open_key directly. Hope it can help you! Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Wednesday, May 13, 2020 5:47 PM To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Query on persistent keys Crypto API Hi, Support for generating and working with persistent keys was recently merged into TF-M in the following change request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252/8 This corresponds to section 3.2.2 (Persistent keys) of the PSA Cryptography API 1.0 (dated 19/02/2020), although there seems to be some delay in implementing the functionality described in the API document. Page 209 ("Changes between 1.0 beta 3 and 1.0.0") states: "Removed psa_open_key and psa_close_key", but these functions are both present in the repo and seem to be used in the tests here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry… Presumably this positions the merged change request around 1.0 beta 3, just to know where we stand with the API documentation versus implementation in TF-M? Since this is a very useful feature in real world applications, I was working on a sample application in Zephyr demonstrating how it might be used during device provisioning, and I was hoping to better understand the differences between the implementation in TF-M today and the 1.0 API document, specifically around KEY IDs versus key handle based access? The 1.0 API documentation, for example, describes: psa_status_t psa_export_public_key(psa_key_id_t key, uint8_t * data, size_t data_size, size_t * data_length); But TF-M implements this add: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… psa_status_t psa_export_public_key(psa_key_handle_t handle, uint8_t *data, size_t data_size, size_t *data_length); Presumably this migration to ID based accesses (versus handles) is still a work in progress, with a goal of perhaps being complete for 1.1? Should I still be calling psa_open_key in the interim, for example? Some examples like the AES + PKCS#7 test case here use that: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry… However, when I try to use psa_open_key when working with PSA_ECC_CURVE_SECP256R1, I get an INSUFFICIENT_MEMORY error, and I'm not sure how to get the psa_key_handle_t for subsequent operations like reading the key back. I've posted the WIP code that fails trying to open the key here: https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05#file-… If I comment out the psa_open_key call, I CAN access the public key in the next function, but only because I have a reference to the handle from when we first persisted the key, but I wouldn't have that handle in the real world if I was accessing a previously created key, and it seems we can't access persisted keys via ID yet, only handles, unless I'm missing something (perhaps obvious)? Best regards, Kevin

4 years, 11 months

2
1
0 0

Query on persistent keys Crypto API

by Kevin Townsend

Hi, Support for generating and working with persistent keys was recently merged into TF-M in the following change request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252/8 This corresponds to section 3.2.2 (Persistent keys) of the PSA Cryptography API 1.0 (dated 19/02/2020), although there seems to be some delay in implementing the functionality described in the API document. Page 209 ("Changes between 1.0 beta 3 and 1.0.0") states: "Removed psa_open_key and psa_close_key", but these functions are both present in the repo and seem to be used in the tests here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry… Presumably this positions the merged change request around 1.0 beta 3, just to know where we stand with the API documentation versus implementation in TF-M? Since this is a very useful feature in real world applications, I was working on a sample application in Zephyr demonstrating how it might be used during device provisioning, and I was hoping to better understand the differences between the implementation in TF-M today and the 1.0 API document, specifically around KEY IDs versus key handle based access? The 1.0 API documentation, for example, describes: psa_status_t psa_export_public_key(psa_key_id_t key, uint8_t * data, size_t data_size, size_t * data_length); But TF-M implements this add: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… psa_status_t psa_export_public_key(psa_key_handle_t handle, uint8_t *data, size_t data_size, size_t *data_length); Presumably this migration to ID based accesses (versus handles) is still a work in progress, with a goal of perhaps being complete for 1.1? Should I still be calling psa_open_key in the interim, for example? Some examples like the AES + PKCS#7 test case here use that: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry… However, when I try to use psa_open_key when working with PSA_ECC_CURVE_SECP256R1, I get an INSUFFICIENT_MEMORY error, and I'm not sure how to get the psa_key_handle_t for subsequent operations like reading the key back. I've posted the WIP code that fails trying to open the key here: https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05#file-… If I comment out the psa_open_key call, I CAN access the public key in the next function, but only because I have a reference to the handle from when we first persisted the key, but I wouldn't have that handle in the real world if I was accessing a previously created key, and it seems we can't access persisted keys via ID yet, only handles, unless I'm missing something (perhaps obvious)? Best regards, Kevin

4 years, 11 months

1
0
0 0

Profile Small design document is merged

by David Hu

Hi all, Profile Small design document is merged into TF-M design documents. Thanks again for your help and reviews. Comments and feedbacks are still and always welcome. The patch set to enable Profile Small is uploaded and under review. Could you please take a look at https://review.trustedfirmware.org/q/topic:%22profile-s-config%22+(status:o… Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, May 7, 2020 12:03 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Request for final review of Profile Small design document Hi all, Profile Small design document has been reviewed for a long time. Thanks a lot for all your comments and suggestions. I'd like to request a final round review. If no further critical comment, the Profile Small design document will be merged next Wednesday. If you have interest in reading the document again, please access https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598. Best regards, Hu Ziji

4 years, 11 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - May 14

by Andrew Thoelke

Hi, Following on from the presentation and discussion on Ken's "Default Handles" proposal on 30 April, we have made some updates following the feedback and further implementation consideration. I (or Ken if he attends) can present an update on the proposal. I also mentioned last time that there is some missing context for this proposal. We are working on an update for PSA-FF-M v1.1 that will provide an enhancement of the v1.0 'IPC model' for secure services, and also a 'Secure Function model' which is similar to the 'library model' of TF-M today. The objective is a single architecture that enables secure service developers to select the framework features required for the complexity of the service; and the framework implementation to be optimised for simple systems. On Thursday, I would like to present an introduction to this PSA-FF-M v1.1 roadmap, and outline the steps that we think are required. Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 06 May 2020 10:17 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - May 14 Hello, The next Technical Forum is planned on Thursday, May 14 at 15:00-16:00 UTC. Please reply on this email with your proposals for agenda topics. To avoid confusion here are some local times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=… Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 14 May 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, 14 May 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, 14 May 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, 14 May 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Best regards, Anton Komlev

4 years, 11 months

1
0
0 0

Re: [TF-M] [TF-A] Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hi all, On 5/5/20 9:04 AM, Sandrine Bailleux via TF-A wrote: > I've received very little feedback on version 2 of the proposal, which > hints that we are reaching an agreement. Thus, I plan to finalize the > proposal this week. This can then become part of our development flow > for all trustedfirmware.org projects. > > Thanks again for all the inputs! The project maintenance process is now live. The document has been moved here (with a few minor edits to turn it from a proposal to an effective process): https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Thanks! Regards, Sandrine

4 years, 11 months

1
0
0 0

TFM 1.0 integration merged into upcoming Zephyr 2.3

by Kevin Townsend

Hi, Just as a FYI, TF-M 1.0 support was merged into Zephyr RTOS this week, meaning that it will be included by default in Zephyr starting with the upcoming 2.3 release. Zephyr is used on the non-secure side, and TF-M is used on the secure side, with the TF-M build happening as part of the normal Zephyr build process, meaning no knowledge of TF-M internals is required to get started. It's also worth highlighting QEMU integration with Zephyr+TF-M. Using the MPS2 AN521 target, you can run application from the command-line with QEMU, meaning that you can create test applications that use the PSA APIs with no HW required, or perform certain application tests purely in SW. As an example, the following sample was run with a clean install of Zephyr, showing QEMU output and demonstrating how to use the initial attestation, crypo and secure storage services: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/tfm_integr… $ mkdir zephyrtfm && cd zephyrtfm $ west init $ west update $ west build -p -b mps2_an521_nonsecure zephyr/samples/tfm_integration/psa_level_1/ -t run [INF] Starting bootloader [INF] Swap type: none [INF] Swap type: none [INF] Bootloader chainload address offset: 0x80000 [INF] Jumping to the first image slot [Sec Thread] Secure image initializing! TF-M isolation level is: 1 Booting TFM v1.0 *** Booting Zephyr OS build zephyr-v2.2.0-2701-ge5aaf21a73c7 *** [00:00:00.003,000] <inf> app: app_cfg: Creating new config file with UID 0x155cfda7a [00:00:03.518,000] <inf> app: att: System IAT size is: 545 bytes. [00:00:03.518,000] <inf> app: att: Requesting IAT with 64 byte challenge. [00:00:06.925,000] <inf> app: att: IAT data received: 545 bytes. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 D2 84 43 A1 01 26 A0 59 01 D5 AA 3A 00 01 24 FF ..C..&.Y...:..$. 00000010 58 40 00 11 22 33 44 55 66 77 88 99 AA BB CC DD X@.."3DUfw...... 00000020 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000030 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000040 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000050 EE FF 3A 00 01 24 FB 58 20 A0 A1 A2 A3 A4 A5 A6 ..:..$.X ....... 00000060 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 ................ 00000070 B7 B8 B9 BA BB BC BD BE BF 3A 00 01 25 00 58 21 .........:..%.X! 00000080 01 FA 58 75 5F 65 86 27 CE 54 60 F2 9B 75 29 67 ..Xu_e.'.T`..u)g 00000090 13 24 8C AE 7A D9 E2 98 4B 90 28 0E FC BC B5 02 .$..z...K.(..... 000000A0 48 3A 00 01 24 FA 58 20 AA AA AA AA AA AA AA AA H:..$.X ........ 000000B0 BB BB BB BB BB BB BB BB CC CC CC CC CC CC CC CC ................ 000000C0 DD DD DD DD DD DD DD DD 3A 00 01 24 F8 20 3A 00 ........:..$. :. 000000D0 01 24 F9 19 30 00 3A 00 01 24 FD 82 A5 01 63 53 .$..0.:..$....cS 000000E0 50 45 04 65 30 2E 30 2E 30 05 58 20 BF E6 D8 6F PE.e0.0.0.X ...o 000000F0 88 26 F4 FF 97 FB 96 C4 E6 FB C4 99 3E 46 19 FC .&..........>F.. 00000100 56 5D A2 6A DF 34 C3 29 48 9A DC 38 06 66 53 48 V].j.4.)H..8.fSH 00000110 41 32 35 36 02 58 20 B4 74 47 EE 2A 2C A4 73 B2 A256.X .tG.*,.s. 00000120 A5 55 D4 73 6D 7F 8B 42 97 94 C2 36 BC 03 33 04 .U.sm..B...6..3. 00000130 29 C3 E5 9C FF CD C4 A5 01 64 4E 53 50 45 04 65 )........dNSPE.e 00000140 30 2E 30 2E 30 05 58 20 B3 60 CA F5 C9 8C 6B 94 0.0.0.X .`....k. 00000150 2A 48 82 FA 9D 48 23 EF B1 66 A9 EF 6A 6E 4A A3 *H...H#..f..jnJ. 00000160 7C 19 19 ED 1F CC C0 49 06 66 53 48 41 32 35 36 |......I.fSHA256 00000170 02 58 20 07 16 EE 98 EA 6A CC 0F 7A 9A 21 46 E6 .X .....j..z.!F. 00000180 CD 26 B4 0B 3D 4B 35 B4 9C B1 89 57 56 12 66 AB .&..=K5....WV.f. 00000190 72 BD 47 3A 00 01 25 01 77 77 77 77 2E 74 72 75 r.G:..%.wwww.tru 000001A0 73 74 65 64 66 69 72 6D 77 61 72 65 2E 6F 72 67 stedfirmware.org 000001B0 3A 00 01 24 F7 71 50 53 41 5F 49 4F 54 5F 50 52 :..$.qPSA_IOT_PR 000001C0 4F 46 49 4C 45 5F 31 3A 00 01 24 FC 72 30 36 30 OFILE_1:..$.r060 000001D0 34 35 36 35 32 37 32 38 32 39 31 30 30 31 30 58 456527282910010X 000001E0 40 51 33 D9 87 96 A9 91 55 18 9E BF 14 7A E1 76 @Q3.....U....z.v 000001F0 F5 0F A6 3C 7B F2 3A 1B 59 24 5B 2E 67 A8 F8 AB ...<{.:.Y$[.g... 00000200 12 A3 AC 9C E8 44 95 13 60 82 E9 49 43 7B 4E C5 .....D..`..IC{N. 00000210 2C 0D E5 EC BA 72 C5 35 2C F7 C9 1C B7 26 93 80 ,....r.5,....&.. 00000220 12 . [00:00:06.982,000] <inf> app: Generating 256 bytes of random data. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 0C 90 D8 0C FA 0F 97 00 29 B2 AE 5C 90 48 3D 39 ........)..\.H=9 00000010 00 14 6C A3 84 E2 C0 C9 82 F5 8B A6 E9 38 66 16 ..l..........8f. 00000020 EA B7 E7 78 91 0D 6D 87 5B B8 04 0B 8B E0 74 23 ...x..m.[.....t# 00000030 7D 11 E2 17 32 34 1A 01 71 24 29 D5 7C 05 B1 11 }...24..q$).|... 00000040 A0 97 20 82 03 FF D6 76 9D 6F D5 52 45 C9 E1 17 .. ....v.o.RE... 00000050 69 DF 18 B6 8E 0C AA 3B 74 B4 EF 97 D9 0E 82 25 i......;t......% 00000060 E1 97 0E 6E 4F 0F DE B9 20 60 34 A4 EA 0D 9A B3 ...nO... `4..... 00000070 3F C4 9A CF F3 5E F2 2C 78 96 6F 0E DD E3 E6 CB ?....^.,x.o..... 00000080 DC 19 26 A3 E8 8E 07 0E 1E 5B DB 59 B0 05 41 E2 ..&......[.Y..A. 00000090 A4 ED 90 35 8B AB 1C B8 00 7E BB 2D 22 FE 7A EA ...5.....~.-".z. 000000A0 CF A0 BB DF 4F 2B 32 55 C9 07 0D 3D CE B8 43 78 ....O+2U...=..Cx 000000B0 63 33 6C 79 CA 43 3A 4F 0B 93 33 2B B1 D2 B0 A7 c3ly.C:O..3+.... 000000C0 44 A0 E9 E8 BF FB FD 89 2A 44 7A 60 2D 9B 0F 9E D.......*Dz`-... 000000D0 0D B1 0E 9D 5C 60 5D E6 92 78 36 79 68 37 24 C5 ....\`]..x6yh7$. 000000E0 57 7F 2E DF 53 D2 7B 3F EE 56 9B 9E BB 39 2C B6 W...S.{?.V...9,. 000000F0 AA FF B5 3B 59 4E 40 1D E0 34 50 05 D0 E0 95 12 ...;YN@..4P..... [00:00:07.004,000] <inf> app: Calculating SHA-256 hash of value. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 E3 B0 C4 42 98 FC 1C 14 9A FB F4 C8 99 6F B9 24 00000010 27 AE 41 E4 64 9B 93 4C A4 95 99 1B 78 52 B8 55 A big thanks to Karl, who was involved in getting this integration work going during his time as an assignee to the LITE team at Linaro, and to other members of the Zephyr community who got this over the finish line at the last minute, as well as to Mate for some last second feedback and debugging with TF-M in IPC mode using Zephyr. We hope this will make TF-M, and all the hard work that has gone into it, far more accessible to a wider range of people, with HW no longer being an immediate limitation to trying it out. Best regards, Kevin Townsend, Linaro

4 years, 11 months

1
0
0 0

Remove 'INDIVIDUAL_SW_COMPONENTS' support from attestation

by Tamas Ban

Hi, I let you notify that 'INDIVIDUAL_SW_COMPONENTS' support is planned to be removed from attestation service and bootloader. What is this? * Boootloader and SPE can exchange data through shared memory. This is needed to provide the boot status info to attestation service. The boot status info is included in the SW_COMPONENT claim in the attestation token. * Until now two types of data encoding was supported during this data sharing: * All boot status data item is passed as a single TLV entry: -DATTEST_BOOT_INTERFACE=INDIVIDUAL_CLAIMS * Boot status is already encoded to CBOR format at build time. Bootloader only updates a few field in it, and pass the CBOR object to SPE. Then attestation service just include this already CBOR formatted object to the token, without the need to applying further encoding. -DATTEST_BOOT_INTERFACE=CBOR_ENCODED_CLAIMS The 'INDIVIDUAL_CLAIMS' format is marked as deprecated feature for a while in the code base. Now the plan is to remove it and rely fully on the 'CBOR_ENCODED_CLAIMS' format. The build system support for this is present in TF-M for a long, and recently it was upstream to original MCUBoot 'imgtool' script as well. Next MCUBoot release (v1.6) will contain it. If you has any objection, because your project is using the 'INDIVIDUAL_CLAIMS' format then please let us know! BR, Tamas

4 years, 11 months

1
0
0 0

Request for final review of Profile Small design document

by David Hu

Hi all, Profile Small design document has been reviewed for a long time. Thanks a lot for all your comments and suggestions. I'd like to request a final round review. If no further critical comment, the Profile Small design document will be merged next Wednesday. If you have interest in reading the document again, please access https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598. Best regards, Hu Ziji

4 years, 11 months

1
0
0 0

TF-M Technical Forum call - May 14

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, May 14 at 15:00-16:00 UTC. Please reply on this email with your proposals for agenda topics. To avoid confusion here are some local times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=… Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 14 May 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, 14 May 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, 14 May 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, 14 May 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Best regards, Anton Komlev

4 years, 11 months

1
0
0 0

Invitation: TF-M tech Forum (Asia TZ) @ Every 4 weeks from 07:00 to 08:00 on Thursday from Thu 28 May to Sat 1 Aug (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. 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: Every 4 weeks from 07:00 to 08:00 on Thursday from Thu 28 May to Sat 1 Aug United Kingdom Time 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=MjJva2xwOGVxaG12bHVha… 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, 11 months

1
0
0 0

Invitation: TF-M Tech Forum (US TZ) @ Every 4 weeks from 16:00 to 17:00 on Thursday from Thu 14 May to Sat 1 Aug (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum (US 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: Every 4 weeks from 16:00 to 17:00 on Thursday from Thu 14 May to Sat 1 Aug United Kingdom Time 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=MW5vZW9lcmloY2l2aWhpa… 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, 11 months

1
0
0 0

Re: [TF-M] Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hi all, I've received very little feedback on version 2 of the proposal, which hints that we are reaching an agreement. Thus, I plan to finalize the proposal this week. This can then become part of our development flow for all trustedfirmware.org projects. Thanks again for all the inputs! Regards, Sandrine Bailleux

4 years, 11 months

1
0
0 0

IAR related changes needing review and merge

by Thomas Törnblom

I have submitted a few patches to allow building with IAR after recent changes. https://review.trustedfirmware.org/c/trusted-firmware-m/+/3982 https://review.trustedfirmware.org/c/trusted-firmware-m/+/3997 https://review.trustedfirmware.org/c/trusted-firmware-m/+/4022 I would be happy for review and merge. Thanks, 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, 11 months

1
0
0 0

Re: [TF-M] LPC55S69 support merged into master

by Thomas Törnblom

Hi Kevin, Are there any plans to add ARMCLANG as a build environment for this? If so, then I can add an IAR port as well. Going from ARMCLANG to IAR is much easier than to go from GNUARM to IAR. I have access to one of these boards so will be able to run regression tests as well. Cheers, Thomas Den 2020-04-29 kl. 15:03, skrev Kevin Townsend via TF-M: > Hi, > > Just a quick note that support for the LPC55S69 was just merged in, > allowing you to use the relatively easy to source LPCXpresso55S69-EVK > dev board: > https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… > > Some notes on how to use this board with TF-M are visible here, > including how to update the board to use the Segger J-Link firmware > image: > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… > > Samples scripts for building and flashing (which assume the J-Link > debug firmware is present) are available here: > > - > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… > - > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… > > If you find any issues with the board support, you can comment on the > LPC55S69 task here: https://developer.trustedfirmware.org/T706 > > Best regards, > Kevin Townsend > -- *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, 12 months

2
1
0 0

Improve library model secure function entry points

by David Hu

Hi all, I uploaded a patch (https://review.trustedfirmware.org/c/trusted-firmware-m/+/4009) to simplify/improve the entry points of secure functions in Library model. In current Library model implementation, each secure function includes the same inline entry point tfm_core_partition_request(). Actually, only the NS client check is required to be inline. The duplicated entry points cost much code size. Thus this patch extracts NS client check and make it as a simple inline function tfm_core_is_ns_client(). tfm_core_partition_request() becomes a normal function called by each secure function. Some quantitative results of code size optimization (about 3KB) are shown below: Profile Small (ConfigDefaultProfileS) is based on https://review.trustedfirmware.org/q/topic:%22symmetric-attest%22+(status:o… ConfigDefault + Armclang 6.10 + Release + AN521 Code RO-data RW-data ZI-data Current impl 129778 8994 272 50108 Improved 126294 8994 272 50108 ConfigDefaultProfileS + Armclang 6.10 + Release + AN521 Code RO-data RW-data ZI-data Current impl 55886 3274 200 31664 Improved 52930 3274 200 31664 Best regards, Hu Ziji

4 years, 12 months

1
0
0 0

Re: [TF-M] PSA Crypto failure with addition of persistent keys

by Vinay Kumar Kotegowder

Hi Raymond, There are some changes required for PSoC64 target with the recent changes from Jamie on persistent key support for test_c050 (api-tests/dev_apis/crypto/test_c050). I will be pushing changes to GitHub today. You could try them and let us know if you are still facing problem. Regards, Vinay ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of David Hu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, April 27, 2020 8:03 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com>; Jamie Fox <Jamie.Fox(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] PSA Crypto failure with addition of persistent keys Hi Raymond, Sorry for the trouble. Sorry that I cannot find a Crypto test case with index 250. Could you please share more details and error logs of this test case? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M Sent: Monday, April 27, 2020 10:26 AM To: tf-m(a)lists.trustedfirmware.org; Jamie Fox <Jamie.Fox(a)arm.com> Subject: [TF-M] PSA Crypto failure with addition of persistent keys Hi Jamie, With the addition of persistent key support, we have seen the PSA Crypto test hang at test 250. Although we originally saw this with PSoC64, I was able to reproduce this problem on a Musca-B1. Can you please have a look please? Note that the behavior is not always the same. I have 2x Musca-B1 boards and they both failed the first time I ran the PSA Crypto test suite. However, they both did not freeze on a 2nd run. Possibly a stack issue such that the behavior is dependent on what is in stack. 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 12 months

2
2
0 0

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

by Anton Komlev

Hello, The agenda of the call is: 1. introduction to a mechanism efficiency improvement by reducing 'psa_connect'/'psa_close'calls. 2. Mailing List topics discussion (optional) 3. AOB Best regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 28 April 2020 07:17 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - April 30 Hi Anton, I would like to give a brief introduction for a mechanism which would improve the coding efficiency and performance for RoT Service API by avoiding 'psa_connect'/'psa_close'. BR. /Ken 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, April 23, 2020 3:29 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] TF-M Technical Forum call - April 30 Hello, The next Technical Forum is planned on Thursday, April 30 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

4 years, 12 months

1
0
0 0

Re: [TF-M] LPC55S69 support merged into master

by Andrej Butok

Hi Kevin, Thank you very much for your successfully efforts and taking care for the TFM LPC55S69 upstream. Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Wednesday, April 29, 2020 3:04 PM To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] LPC55S69 support merged into master Hi, Just a quick note that support for the LPC55S69 was just merged in, allowing you to use the relatively easy to source LPCXpresso55S69-EVK dev board: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.c…> Some notes on how to use this board with TF-M are visible here, including how to update the board to use the Segger J-Link firmware image: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> Samples scripts for building and flashing (which assume the J-Link debug firmware is present) are available here: - https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> - https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> If you find any issues with the board support, you can comment on the LPC55S69 task here: https://developer.trustedfirmware.org/T706<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…> Best regards, Kevin Townsend

4 years, 12 months

1
0
0 0

LPC55S69 support merged into master

by Kevin Townsend

Hi, Just a quick note that support for the LPC55S69 was just merged in, allowing you to use the relatively easy to source LPCXpresso55S69-EVK dev board: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… Some notes on how to use this board with TF-M are visible here, including how to update the board to use the Segger J-Link firmware image: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… Samples scripts for building and flashing (which assume the J-Link debug firmware is present) are available here: - https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… - https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… If you find any issues with the board support, you can comment on the LPC55S69 task here: https://developer.trustedfirmware.org/T706 Best regards, Kevin Townsend

4 years, 12 months

1
0
0 0

Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION

by Ken Liu

Hi Reinhard, About the CMSIS documentation change, could you share us the difference to be updated? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Tuesday, April 28, 2020 10:54 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION Hi Ken, Thanks for feedback. TFM_NS_CLIENT_IDENTIFICATION is based on https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The CMSIS documentation is misleading and I can see why you think it is easy to manage secure storage using the same interface. RTOS Thread Context Management<https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…> relates as the name indicates to specific threads. It is used to manage the secure stack space for NS->S function calls that are directly initiated by a thread. When the same mechanism is used to protect permanent storage, it implies that this storage is always accessed by the same thread. However user applications may create/destroy threads (run a different combination of threads) which would break this protection already during run time. Moreover when you update your firmware image on the secure side, the thread IDs (module ID) are likely to change, hence a new firmware version might be unable to retrieve information that was stored by a previous version. Long story short: * I cannot see that TFM_NS_CLIENT_IDENTIFICATION gives us a solution that works in partice. * I will request to fix the CMSIS documentation for "Thread Context Management"; make it clear that is about thread execution. In a nutshell: we should consider to remove TFM_NS_CLIENT_IDENTIFICATION as I cannot see that it works. Reinhard

4 years, 12 months

1
0
0 0

Re: [TF-M] REGION_DECLARE macros

by Sherry Zhang

Hi Thomas, OK, the problem is caused by that the names of region related symbols that IRA compiler generate are different with those of ARMCLANG. The work around below do can solve the problem. BTW the work around seems not to be a general one. I think another way to solve the problem is adding a macro like SYMBOL_NAME_BASE(region) which is a wrapper of the REGION_NAME on different compilers. Regards, Sherry Zhang From: Thomas Törnblom <thomas.tornblom(a)iar.com> Sent: Tuesday, April 28, 2020 6:28 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; TF-M <tf-m-bounces(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] REGION_DECLARE macros Hi Sherry, Yes, I noticed that this change had been integrated and that this symbol was being used. I ran into a lot of these during the IAR port and as I said they don't work with the IAR linker. I work around this in CommonConfig.cmake by this define: --- embedded_set_target_compile_flags(TARGET ${tgt} LANGUAGE C FLAGS ${COMMON_COMPILE_FLAGS} "-DImage$$= " "-DLoad$$LR$$= " "-D$$ZI$$Base=$$Base" "-D$$ZI$$Limit=$$Limit" "-D$$RO$$Base=$$Base" "-D$$RO$$Limit=$$Limit" "-D$$RW$$Base=$$Base" "-D$$RW$$Limit=$$Limit" "-D_DATA$$RW$$Base=_DATA$$Base" "-D_DATA$$RW$$Limit=_DATA$$Limit" "-D_DATA$$ZI$$Base=_DATA$$Base" "-D_DATA$$ZI$$Limit=_DATA$$Limit" "-D_STACK$$ZI$$Base=_STACK$$Base" "-D_STACK$$ZI$$Limit=_STACK$$Limit" --- i.e. I replace $$ZI$$Base with $$Base, Image$$ and Load$$LR are removed entirely, and so on. To make this work I need to split the symbol up into its components, which is done with the REGION macros. So the symbol "Image$$ARM_LIB_STACK_MSP$$ZI$$Base" turns into "ARM_LIB_STACK_MSP$$Base", which is what we use for IAR. For ARMCLANG and GNUARM the macros generate the original symbol. Cheers, Thomas Den 2020-04-28 kl. 12:03, skrev Sherry Zhang: Hi Thomas, The diff below is caused by this patch https://review.trustedfirmware.org/c/trusted-firmware-m/+/3942 . REGION_NAME is used to pasting the input parameters into a string. So there should be no difference between Image$$ARM_LIB_STACK_MSP$$ZI$$Base and REGION_NAME(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base) basing on the current implementation of REGION_NAME in file platform/include/region.h So, is there a specific REGION_NAME macro implementation for IAR compiler? Or the automatically generated region related symbols are with different names in IAR compiler? Regards, Sherry Zhang 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 Sent: Tuesday, April 28, 2020 4:58 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] REGION_DECLARE macros I have no idea what causes the crap characters in the diff below, they should be blanks. Looks like a problem with the mailing list software. Trying another type: /* Set Main Stack Pointer limit */ - extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; - __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); + REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base); + __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, + $$ZI$$Base)); Den 2020-04-28 kl. 10:51, skrev Thomas Tï¿½rnblom via TF-M: With the integration of the IAR toolchain support in TF-M it has become important to use the REGION_DECLARE/REGION_NAME macros in platform/region.h instead of using symbols like "Image$$ARM_LIB_STACK_MSP$$ZI$$Base". The IAR linker can not use these symbols and the macros in combination with the IAR specific cmake rules creates appropriate symbols for all the supported toolchains. Example diff: --- ï¿½ï¿½ï¿½ï¿½ /* Set Main Stack Pointer limit */ -ï¿½ï¿½ï¿½ extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; -ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); +ï¿½ï¿½ï¿½ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,ï¿½ $$ZI$$Base); +ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, +ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ $$ZI$$Base)); --- 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> -- 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>

5 years

1
0
0 0

Questions on TFM_NS_CLIENT_IDENTIFICATION

by Reinhard Keil

Hi Ken, Thanks for feedback. TFM_NS_CLIENT_IDENTIFICATION is based on https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The CMSIS documentation is misleading and I can see why you think it is easy to manage secure storage using the same interface. RTOS Thread Context Management<https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…> relates as the name indicates to specific threads. It is used to manage the secure stack space for NS->S function calls that are directly initiated by a thread. When the same mechanism is used to protect permanent storage, it implies that this storage is always accessed by the same thread. However user applications may create/destroy threads (run a different combination of threads) which would break this protection already during run time. Moreover when you update your firmware image on the secure side, the thread IDs (module ID) are likely to change, hence a new firmware version might be unable to retrieve information that was stored by a previous version. Long story short: * I cannot see that TFM_NS_CLIENT_IDENTIFICATION gives us a solution that works in partice. * I will request to fix the CMSIS documentation for "Thread Context Management"; make it clear that is about thread execution. In a nutshell: we should consider to remove TFM_NS_CLIENT_IDENTIFICATION as I cannot see that it works. Reinhard

5 years

1
0
0 0

Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION

by David Wang

Hi Reinhard, Add more from user's perspective: The non-secure client id can be used to identify different "clients" from non-secure side. The example from tf-m existing secure service is the storage. Different client id can access different storage space. Therefore, the storage is "isolation" among the clients. The users can create the custom secure service and leverage different client ids (let's say non-secure client id here) to identify different non-secure "callers": * The meaning of identifying different non-secure callers depends on the user case of the secure service. For example, different storage spaces, different access permissions, etc. * In RTOS, different non-secure client ids are managed via TZ_APIs (https://www.keil.com/pack/doc/CMSIS/Core/html/group__context__trustzone__fu…) if they're enabled. * The mapping between non-secure applications and the TZ secure contexts (stand for different client ids in tfm) is managed by NS RTOS kernel. When the ns applications get updated, then the mapping should also be maintained by RTOS kernel. Hope this helps. Refs: [1]: TF-M non-secure ID manager http://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/user_guides… [2]: PR to FreeRTOS which uses different non-secure id for storage service: https://github.com/Linaro/amazon-freertos/pull/1 Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Tuesday, April 28, 2020 7:00 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION Hi Reinhard, My assumption on the user side: - For application developers, they don't need to care about the identification and just access secure service via API. - For non-secure OS (or, a whole system level including SPE and NSPE) developers or integrators, they can implement a mechanism to help SPM identify the different non-secure threads, then SPM can do more granular client management (access control or other policies). If the don't, then SPM take whole NSPE shares the same non-secure client id and no more granular client management. Still need the real USER to provide more information in case my assumption covers partial scenarios only. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Reinhard Keil via TF-M Sent: Tuesday, April 28, 2020 2:57 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] Questions on TFM_NS_CLIENT_IDENTIFICATION I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled. However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime. Reinhard

5 years

1
0
0 0

Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION

by Ken Liu

Hi Reinhard, My assumption on the user side: - For application developers, they don't need to care about the identification and just access secure service via API. - For non-secure OS (or, a whole system level including SPE and NSPE) developers or integrators, they can implement a mechanism to help SPM identify the different non-secure threads, then SPM can do more granular client management (access control or other policies). If the don't, then SPM take whole NSPE shares the same non-secure client id and no more granular client management. Still need the real USER to provide more information in case my assumption covers partial scenarios only. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Tuesday, April 28, 2020 2:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled. However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime. Reinhard

5 years

1
0
0 0

Re: [TF-M] REGION_DECLARE macros

by Sherry Zhang

Hi Thomas, The diff below is caused by this patch https://review.trustedfirmware.org/c/trusted-firmware-m/+/3942 . REGION_NAME is used to pasting the input parameters into a string. So there should be no difference between Image$$ARM_LIB_STACK_MSP$$ZI$$Base and REGION_NAME(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base) basing on the current implementation of REGION_NAME in file platform/include/region.h So, is there a specific REGION_NAME macro implementation for IAR compiler? Or the automatically generated region related symbols are with different names in IAR compiler? Regards, Sherry Zhang 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 Sent: Tuesday, April 28, 2020 4:58 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] REGION_DECLARE macros I have no idea what causes the crap characters in the diff below, they should be blanks. Looks like a problem with the mailing list software. Trying another type: /* Set Main Stack Pointer limit */ - extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; - __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); + REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base); + __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, + $$ZI$$Base)); Den 2020-04-28 kl. 10:51, skrev Thomas Tï¿½rnblom via TF-M: With the integration of the IAR toolchain support in TF-M it has become important to use the REGION_DECLARE/REGION_NAME macros in platform/region.h instead of using symbols like "Image$$ARM_LIB_STACK_MSP$$ZI$$Base". The IAR linker can not use these symbols and the macros in combination with the IAR specific cmake rules creates appropriate symbols for all the supported toolchains. Example diff: --- ï¿½ï¿½ï¿½ï¿½ /* Set Main Stack Pointer limit */ -ï¿½ï¿½ï¿½ extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; -ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); +ï¿½ï¿½ï¿½ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,ï¿½ $$ZI$$Base); +ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, +ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ $$ZI$$Base)); --- 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>

5 years

1
0
0 0

Re: [TF-M] REGION_DECLARE macros

by Thomas Törnblom

I have no idea what causes the crap characters in the diff below, they should be blanks. Looks like a problem with the mailing list software. Trying another type: /* Set Main Stack Pointer limit */ - extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; - __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); + REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base); + __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, + $$ZI$$Base)); Den 2020-04-28 kl. 10:51, skrev Thomas Törnblom via TF-M: > With the integration of the IAR toolchain support in TF-M it has > become important to use the REGION_DECLARE/REGION_NAME macros in > platform/region.h instead of using symbols like > "Image$$ARM_LIB_STACK_MSP$$ZI$$Base". > > The IAR linker can not use these symbols and the macros in combination > with the IAR specific cmake rules creates appropriate symbols for all > the supported toolchains. > > Example diff: > --- > ï¿½ï¿½ï¿½ï¿½ /* Set Main Stack Pointer limit */ > -ï¿½ï¿½ï¿½ extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; > -ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); > +ï¿½ï¿½ï¿½ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,ï¿½ $$ZI$$Base); > +ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, > +ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > $$ZI$$Base)); > --- > > 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>

5 years

1
0
0 0

REGION_DECLARE macros

by Thomas Törnblom

With the integration of the IAR toolchain support in TF-M it has become important to use the REGION_DECLARE/REGION_NAME macros in platform/region.h instead of using symbols like "Image$$ARM_LIB_STACK_MSP$$ZI$$Base". The IAR linker can not use these symbols and the macros in combination with the IAR specific cmake rules creates appropriate symbols for all the supported toolchains. Example diff: --- /* Set Main Stack Pointer limit */ - extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; - __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); + REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base); + __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, + $$ZI$$Base)); --- 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>

5 years

1
0
0 0

Questions on TFM_NS_CLIENT_IDENTIFICATION

by Reinhard Keil

I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled. However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime. Reinhard

5 years

1
0
0 0

Re: [TF-M] Documentation for platform interfaces

by Minos Galanakis

Hi Reinhard I think the closer to a high level documentation is this page: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… To your question regarding the nv counters, they are currently used by MCUBOOT and Protected Storage Service. You may be interested in this patch under review which is will expose them as a service https://review.trustedfirmware.org/c/trusted-firmware-m/+/3367 Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Reinhard Keil via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 27 April 2020 16:07 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Documentation for platform interfaces Is there somewhere a high-level documentation for the platform interfaces that are here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/includ… What are the dependencies of the services to the platform files? For example, when is nv_counters used? Reinhard

5 years

2
1
0 0

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

by Ken Liu

Hi Anton, I would like to give a brief introduction for a mechanism which would improve the coding efficiency and performance for RoT Service API by avoiding 'psa_connect'/'psa_close'. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, April 23, 2020 3:29 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - April 30 Hello, The next Technical Forum is planned on Thursday, April 30 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years

1
0
0 0

Documentation for platform interfaces

by Reinhard Keil

Is there somewhere a high-level documentation for the platform interfaces that are here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/includ… What are the dependencies of the services to the platform files? For example, when is nv_counters used? Reinhard

5 years

1
0
0 0

Re: [TF-M] PSA Crypto failure with addition of persistent keys

by David Hu

Hi Raymond, Sorry for the trouble. Sorry that I cannot find a Crypto test case with index 250. Could you please share more details and error logs of this test case? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M Sent: Monday, April 27, 2020 10:26 AM To: tf-m(a)lists.trustedfirmware.org; Jamie Fox <Jamie.Fox(a)arm.com> Subject: [TF-M] PSA Crypto failure with addition of persistent keys Hi Jamie, With the addition of persistent key support, we have seen the PSA Crypto test hang at test 250. Although we originally saw this with PSoC64, I was able to reproduce this problem on a Musca-B1. Can you please have a look please? Note that the behavior is not always the same. I have 2x Musca-B1 boards and they both failed the first time I ran the PSA Crypto test suite. However, they both did not freeze on a 2nd run. Possibly a stack issue such that the behavior is dependent on what is in stack. 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years

1
0
0 0

PSA Crypto failure with addition of persistent keys

by Raymond Ngun

Hi Jamie, With the addition of persistent key support, we have seen the PSA Crypto test hang at test 250. Although we originally saw this with PSoC64, I was able to reproduce this problem on a Musca-B1. Can you please have a look please? Note that the behavior is not always the same. I have 2x Musca-B1 boards and they both failed the first time I ran the PSA Crypto test suite. However, they both did not freeze on a 2nd run. Possibly a stack issue such that the behavior is dependent on what is in stack. 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.

5 years

1
0
0 0

Re: [TF-M] [RFC] The veneer usage under library model

by Ken Liu

Looks no more feedbacks. We will start creating it and call for review when finished. Issue created for collecting comments: https://developer.trustedfirmware.org/T720 Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Thursday, April 9, 2020 4:32 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] The veneer usage under library model (Ken Liu) Hi Reinhard, Thanks for your feedback, and let's see if others would give more comments. Will broadcast the implementation after it is created. Before that we need to know if some users (especially those developing secure partitions under library model) got comments on this. Also, I think this update could help the first point in your list. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, April 9, 2020 2:57 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] [RFC] The veneer usage under library model (Ken Liu) Ken, This is the answer to "What do you think about this update?" When external TF-M APIs do not change, there should be no user impact. As the veneer is just an internal implementation of parameter passing, changing the veneer implementation would be just fine. I made some suggestions here https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html I would be happy to review your implementation in case that you have doubts. Best regards Reinhard

5 years

1
0
0 0

Request for comments on TF-M Profile Small design updates

by David Hu

Hi all, Hope you are doing well. May I ask for your review on the latest Profile Small design? The design has been updated with following major changes: * The default AES mode is changed to CCM mode from CBC mode, to achieve more secured connection. * More details on the use case of Profile Small Please review the document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598. Please feel free to comment. Thank you! The patch set is updated as well, following the latest design. Please check it on https://review.trustedfirmware.org/q/topic:%22profile-s-config%22+(status:o…. Compared with previous versions, CCM is supported and some configurations are selected to optimize the Crypto memory footprint. Best regards, Hu Ziji

5 years

1
0
0 0

TF-M Technical Forum call - April 30

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, April 30 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Tamas Ban

Bug fix merged: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3943 -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:26 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Bug being tracked at https://developer.trustedfirmware.org/T716, aiming to get the fix pushed in a few minutes Raef ________________________________________ 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: 20 April 2020 13:06 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Thanks Thomas to let us know! Fix will be pushed soon! -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ 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: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Raef Coles

Bug being tracked at https://developer.trustedfirmware.org/T716, aiming to get the fix pushed in a few minutes Raef ________________________________________ 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: 20 April 2020 13:06 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Thanks Thomas to let us know! Fix will be pushed soon! -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ 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: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Tamas Ban

Thanks Thomas to let us know! Fix will be pushed soon! -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ 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: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M