February 2023 - TF-M - lists.trustedfirmware.org

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 7, 15:00-16:00 UTC (West time zone). Please reply on this email with your proposals for agenda topics. Link to the forum: https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

1 week, 5 days

10
56
0 0

Technical Forum call - July 21

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 21, 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Link to the forum: https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 weeks, 6 days

7
54
0 0

Re: Attestation token new spec

by Tamas Ban

Hi, Sorry 2nd link was broken. Here is the working version: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab… Tamas Ban From: Andersson, Joakim <Joakim.Andersson(a)nordicsemi.no> Sent: 2022. május 9., hétfő 12:14 To: Tamas Ban <Tamas.Ban(a)arm.com> Subject: RE: Attestation token new spec Is te second link broken? I get a 404 error code. -Joakim From: Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: mandag 9. mai 2022 11:31 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] Attestation token new spec Hi, the initial attestation token implementation is aligned with this specification: https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-05<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack…> This spec is still evolving and there is a newer version which changes the key values of the claims in the token: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab…<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.…> This can cause combability issues between token issuer (device) and token verifier (some remote verification service). This is an ABI change between token issuer and consumer. The breaking effect would be manifest in unaccepted IAT tokens by the verifier. On-device side I see these options to make the transition: - A build-time option could be introduced which determines which range of key numbers to use. The default value would be the new range. To not let new users pick up the old values accidentally. Existing users can notice the incompatibility issue during the integration test and adjust their build command accordingly. However, the old range would be announced as deprecated in the next TF-M release, then will be removed in the next release after. - Immediate switch over to the new range, without supporting the old range anymore. On the verification service side, an SW update can handle the transition and might be accepting both ranges for a while. I assume the verification service can be updated more easily than remote devices therefore better to handle the compatibility issue there. - Keeping the support for both ranges for the long term and letting users choose by build time. Please share your thoughts on: - Are you aware that the attestation service is used in deployed devices where this transition can cause incompatibility? - From the above list which option would you vote to support the transition? Best regards, Tamas Ban

4 months, 1 week

3
4
0 0

Split build

by Bohdan.Hunko＠infineon.com

Hi everyone, Some time ago patch for split build<https://review.trustedfirmware.org/q/topic:%2522split-build%2522> of SPE, NSPE, BL2 was announced. I am interested on when this patch is planned to be merged? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

11 months, 1 week

4
5
0 0

Partitions without manifest files are not linked correctly in L3

by Bohdan.Hunko＠infineon.com

In isolation level 3 partitions code/data in linker script are gathered together and aligned using information from manifest files. Currently there are 2 partitions that are not using manifest files, and instead have hand written load_info.c files. These partitions are: NS agent trust zone and idle partition. When partition does not have manifest file then its code/data is not gathered together (as there is no manifest to provide needed information). This results in partition code/data being linked directly to SPM. Also code/data may be not correctly aligned (if platform requires special alignment for PSA/APP RoT partitions). For example if platform define custom TFM_LINKER_PSA_ROT_LINKER_DATA_ALIGNMENT, NS agent TZ and idle partitions stacks will not be aligned properly. This is a problem because resulting alignment is not sufficient for the platform, which means that functions that apply protections fail. I see several solutions to this problem: 1. Add alignment to stack of these special partitions. Both the start and the size of the stack should be aligned to satisfy alignment requirements. This is fairly easy fix with small amount of changes. The problem is that code/data of these partitions will still be located in SPM code/data sections which is not ideal solution. I would say this is bare minimum solution, just to make things work. 2. Better solution might be to move these special partitions to now use manifest files. The problem I see is that these partition use special priorities values which are not supported by manifest tool. Also NS Agent TZ uses special PID = 0, which I believe is also not supported by manifest tool. I think this is more time consuming fix but overall this should result in better and easier to understand code. Would be glad to hear a feedback on this topic. Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

1 year, 1 month

2
3
0 0

tfm_hal_memory_symbols

by Chris.Brand＠infineon.com

Hi, I'm looking at https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=df87… which added tfm_hal_memory_symbols.{c|h}, containing tfm_hal_sp_meta_start and tfm_hal_sp_meta_end. The former is used in backend_ipc.c, while the latter is unused. The commit message says "this is the first example of using defined symbols to get memory info" but that commit is over two years old now and there doesn't seem to be a second example. Is there still a plan to move in this direction? If so, can somebody outline what that involves? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

1 year, 1 month

2
2
0 0

Trusted Firmware-M Technical Overview document

by Joseph Yiu

Hi all, With a lot of helps from the TF-M team, I have prepared a Trusted Firmware-M Technical Overview document, available here: https://www.trustedfirmware.org/blog/TF-M-TechOverview/ In addition to various general concepts about Trusted Firmware-M, this document also introduces several new features in TF-M v1.7. Thanks to the TF-M team for their helps in preparing this document! :-) Regards, Joseph

1 year, 1 month

1
0
0 0

Default implementation of tfm_ns_interface_dispatch()

by Bohdan.Hunko＠infineon.com

Hi all, While working on TFM TZ related stuff I have noticed that TFM docs/integration_guide/index.rst states that * On Armv8-M TrustZone based platforms, NS OS shall implement interface API ``tfm_ns_interface_dispatch()`` to integrate with TF-M implementation of PSA APIs. But currently neither CMSIS RToS nor FreeRToS implements this function, also there is no default implementation for bare metal case. So currently it is user responsibility to implement this function. Also currently for TFM tests it is implemented in test repository (<tf-m-tests repo>/ app/tfm_ns_interface.c). I think this is bad user experience because each user have to implement this function. I think TFM should provide implementation of this function for most common use cases (for example, CMSIS RToS, AWS FreeRToS, bare metal, ...). Files with implementation should be installed during build process. Default implementations will cover most of use cases and will fit for majority of the users. This way TFM will be more user friendly. What are your thoughts on this topic? Will TFM accept such a patch? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

1 year, 2 months

3
10
0 0

Fw: Re: GCC build error of PSA Arch test with TF-M V1.6.0 and TF-M V1.7.0

by Edward Yang

Hi all, Thanks for your helpful advice, yes, the build error caused by Ubuntu own GCC compiler. I just relink the gcc to GCC 4.8.5 instead of GCC 5.2 (both GCC versions are installed in my Ubuntu environment), then build succeed. Best Regards, Poppy Wu ��ƫƫ Macronix Microelectronics (Suzhou) Co.,Ltd "Bohdan.Hunko--- via TF-M" <tf-m(a)lists.trustedfirmware.org> 2023/02/10 04:58 Please respond to Bohdan.Hunko(a)infineon.com To <Anton.Komlev(a)arm.com>, <David.Hu(a)arm.com>, <Summer.Qin(a)arm.com>, <edwardyang(a)mxic.com.cn>, <tf-m(a)lists.trustedfirmware.org> cc Antonio.DeAngelis(a)arm.com, Ken.Liu(a)arm.com, Kevin.Peng(a)arm.com, nd(a)arm.com Subject [TF-M] Re: GCC build error of PSA Arch test with TF-M V1.6.0 and TF-M V1.7.0 Hi all, I think I know what the problem is. I believe it is related to the problem I have reported earlier in mailing thread https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.… Problem occurs during built of psa_generate_database target. The same was reported by me in the mailing thread. The only difference is that I used Windows. So I have investigated the problem and found the solution, hope it will help you. Turns out PSA arch tests use native platform compiler (e.g. GCC for windows) to compile some generated files and then these compiled files are used in the rest of the build using compiler for arm platform. <psa-arch-tests>/api-tests/CMakeLists.txt adds External project (ExternalProject_Add()) which generates the device database that is needed for the rest of the build. As I said psa_generate_database built invokes native compiler, so call to cc1 is not the call to gcc-arm-none-eabi-10.3-2021.10/lib/gcc/arm-none-eabi/10.3.1/cc1, it is a call to linux native cc1 compiler (to compile given .c file to be executed on Linux) I have installed llvm-mingw and added its bin folder to PATH and this fixed the problem. I think GCC (or other native compilers) will also work. Looks like ARM TF-M team has native compiler installed on their working machines so arch tests build works right away. So my suggestion is to install linuz native cc1 compiler and add it to the PATH Please let me know if this fixed the problem. Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com From: Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 9 February 2023 15:23 To: David Hu <David.Hu(a)arm.com>; Summer Qin <Summer.Qin(a)arm.com>; Edward Yang <edwardyang(a)mxic.com.cn> Cc: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com>; Kevin Peng <Kevin.Peng(a)arm.com>; nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Re: GCC build error of PSA Arch test with TF-M V1.6.0 and TF-M V1.7.0 Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe. Hi, I cut the bottom part of this thread to speedup communication because mailing server asks for approval every mail bigger 80Kb. Cheers, Anton From: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, February 9, 2023 8:35 AM To: Summer Qin <Summer.Qin(a)arm.com>; Edward Yang <edwardyang(a)mxic.com.cn> Cc: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; Ken Liu < Ken.Liu(a)arm.com>; Kevin Peng <Kevin.Peng(a)arm.com>; nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Re: GCC build error of PSA Arch test with TF-M V1.6.0 and TF-M V1.7.0 Hi Poppy, Can you please try the following? Reinstall build-essential Make sure your toolchain is set in PATH Please double check if cc1 exists in your toolchain. My cc1 is found under gcc-arm-none-eabi-10.3-2021.10/lib/gcc/arm-none-eabi/10.3.1/ Best regards, Hu Ziji From: Summer Qin <Summer.Qin(a)arm.com> Sent: Thursday, February 9, 2023 4:20 PM To: Edward Yang <edwardyang(a)mxic.com.cn> Cc: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; David Hu < David.Hu(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com>; Kevin Peng < Kevin.Peng(a)arm.com>; nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org; Poppy Wu <poppywu(a)mxic.com.cn> Subject: Re: [TF-M] GCC build error of PSA Arch test with TF-M V1.6.0 and TF-M V1.7.0 Hi Edward, It seems the local build environment issue, could you try to manually add the cc1 path into PATH, and try to build. Best Regards, Summer From: Edward Yang <edwardyang(a)mxic.com.cn> Sent: Thursday, February 9, 2023 3:14 PM To: Summer Qin <Summer.Qin(a)arm.com> Cc: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; David Hu < David.Hu(a)arm.com>; Ken Liu <Ken.Liu(a)arm.com>; Kevin Peng < Kevin.Peng(a)arm.com>; nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org < tf-m(a)lists.trustedfirmware.org>; Poppy Wu <poppywu(a)mxic.com.cn> Subject: Re: [TF-M] GCC build error of PSA Arch test with TF-M V1.6.0 and TF-M V1.7.0 Hi Summer, I have shorten the project path, still the same. And I have checked cc1 does exist in the folder. By the way, I'm using Ubuntu 16.04, is this probably the reason for building error? [Screenshot and build log removed to reduce mail thread size] -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/src/psa_generate_database-build [ 52%] No build step for 'psa_generate_database' [ 52%] Performing install step for 'psa_generate_database' [ 20%] [PSA] : Creating generator source /home/a/workspace1/TF-M/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/targetConfigGen.c Cannot open input file /home/a/workspace1/TF-M/psa-arch-tests/api-tests/platform/targets/tgt_dev_apis_tfm_stm32l562e_dk/target.cfg Scanning dependencies of target TargetConfigGen [ 40%] Building C object CMakeFiles/TargetConfigGen.dir/home/a/workspace1/TF-M/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/targetConfigGen.c.o cc: error trying to exec 'cc1': execvp: No such file or directory CMakeFiles/TargetConfigGen.dir/build.make:85: recipe for target 'CMakeFiles/TargetConfigGen.dir/home/a/workspace1/TF-M/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/targetConfigGen.c.o' failed make[5]: *** [CMakeFiles/TargetConfigGen.dir/home/a/workspace1/TF-M/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/targetConfigGen.c.o] Error 1 CMakeFiles/Makefile2:96: recipe for target 'CMakeFiles/TargetConfigGen.dir/all' failed make[4]: *** [CMakeFiles/TargetConfigGen.dir/all] Error 2 Makefile:148: recipe for target 'all' failed make[3]: *** [all] Error 2 tf-m-tests/app/psa_api_tests/CMakeFiles/psa_generate_database.dir/build.make:93: recipe for target 'tf-m-tests/app/psa_api_tests/src/psa_generate_database-stamp/psa_generate_database-install' failed make[2]: *** [tf-m-tests/app/psa_api_tests/src/psa_generate_database-stamp/psa_generate_database-install] Error 2 CMakeFiles/Makefile2:1905: recipe for target 'tf-m-tests/app/psa_api_tests/CMakeFiles/psa_generate_database.dir/all' failed make[1]: *** [tf-m-tests/app/psa_api_tests/CMakeFiles/psa_generate_database.dir/all] Error 2 Makefile:148: recipe for target 'all' failed make: *** [all] Error 2 (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trusted-firmware-m/cmake_build# Best Regards, Poppy Wu 吴偏�?br> Macronix Microelectronics (Suzhou) Co.,Ltd Summer Qin via TF-M <tf-m(a)lists.trustedfirmware.org> 2023/02/08 17:51 Please respond to Summer Qin <Summer.Qin(a)arm.com> To Antonio De Angelis <Antonio.DeAngelis(a)arm.com>, " tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>, Edward Yang <edwardyang(a)mxic.com.cn> cc Ken Liu <Ken.Liu(a)arm.com>, Kevin Peng <Kevin.Peng(a)arm.com>, David Hu < David.Hu(a)arm.com>, nd <nd(a)arm.com> Subject [TF-M] Re: GCC build error of PSA Arch test with TF-M V1.6.0 and TF-M V1.7.0 Hi Edward, We tried to reproduce it with the same environment with yours, but could not reproduce the build error, it builds successfully. Any update? By the way, noticed your path is long and contains two tfm folder name, is it nested? Try to simplify the path and try again? Best Wishes, Summer From: Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, February 7, 2023 1:15 PM To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: Ken Liu <Ken.Liu(a)arm.com>; Kevin Peng <Kevin.Peng(a)arm.com>; David Hu < David.Hu(a)arm.com> Subject: [TF-M] GCC build error of PSA Arch test with TF-M V1.6.0 and TF-M V1.7.0 Hi Antonio, Thanks for your suggestions. Indeed, if TEST_PSA_API is disabled, the build will succeed. So I suppose this build error is specific to PSA Arch test build, but I haven't got a clue about which files should be checked, any guidance would be appreciated. Best Regards, Poppy Wu 吴偏�?br> Macronix Microelectronics (Suzhou) Co.,Ltd Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> 2023/02/06 23:27 Please respond to Antonio De Angelis <Antonio.DeAngelis(a)arm.com> To Edward Yang <edwardyang(a)mxic.com.cn>, "tf-m(a)lists.trustedfirmware.org" < tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject [TF-M] Re: gcc build error with TF-M v1.6.0 and v1.7.0 Hi, This looks like an issue with the toolchain, as cc1 should be configured correctly (in the correct $PATH) in your build environment. I am not sure about the specific solution for this, can only suggest to: 1. Make sure that cc1 is part of your toolchain installation 2. PATH is set correctly You can also check if this happens with the default build (i.e. not with PSA Arch tests). In case this is specific to PSA Arch test build, suggest to check with them directly. Hope this somehow helps. /Antonio From: Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, February 6, 2023 04:02 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] gcc build error with TF-M v1.6.0 and v1.7.0 Hi experts, Recently we're testing TF-M v1.6.0, but a build error was encountered as shown below in red box. [Screenshot and build log removed to reduce mail thread size] We've reinstalled the dependency tools as described in TF-M "Getting Started Guide", besides the same gcc tool works fine with TF-M v1.4.0, are there anything we've ignored? Best Regards, Poppy Wu 吴偏�?/font> Macronix Microelectronics (Suzhou) Co.,Ltd-- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org -- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org-- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org

1 year, 2 months

4
5
0 0

SPM source and internal function changes

by Ken Liu

Hello, There would be some changes to SPM sources and functions in these two months. The intention is to provide more abstraction and size optimization for SPM. Some details are: - Create dedicated sources for specific functionality, which could be selected by the configuration system. This could make out an efficient configuration result for easier integration. - Reduce the interfaces exposed between external and internal modules. Such as using only signals to connect thread and ffm logic. There are some ongoing patches for reference: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/19263 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/19073 You can find more related patches from these two above. Comments or contributions are warmly welcome! BR /Ken

1 year, 2 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M February 2023