- TF-M - lists.trustedfirmware.org

by Maulik Patel

Hello Bohdan The PSA token spec v2.0 is still in draft and hence is not yet supported by the psa-arch-tests. I am not aware of the specific plan/timelines, but could you please contact psa-arch-tests team to know details? Best Regards, Maulik ________________________________ From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org> Sent: 27 February 2024 12:00 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Digest, Vol 64, Issue 12 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Re: Attest token v2.0 in psa-arch-tests (Bohdan.Hunko(a)infineon.com) ---------------------------------------------------------------------- Message: 1 Date: Mon, 26 Feb 2024 10:50:38 +0000 From: <Bohdan.Hunko(a)infineon.com> Subject: [TF-M] Re: Attest token v2.0 in psa-arch-tests To: <tf-m(a)lists.trustedfirmware.org> Cc: Kostiantyn.Tkachov(a)infineon.com, Roman.Mazurak(a)infineon.com, Hennadiy.Kytsun(a)infineon.com Message-ID: <be7dcff9aa504e3f894b7f4fd263512d(a)infineon.com> Content-Type: multipart/alternative; boundary="_000_be7dcff9aa504e3f894b7f4fd263512dinfineoncom_" Hi all, Any updates on this? 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> From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, February 19, 2024 15:24 To: tf-m(a)lists.trustedfirmware.org Cc: Tkachov Kostiantyn (CSS ICW SW FW) <Kostiantyn.Tkachov(a)infineon.com>; Mazurak Roman (CSS ICW SW FW 3) <Roman.Mazurak(a)infineon.com>; Kytsun Hennadiy (CSS ICW SW FW 3) <Hennadiy.Kytsun(a)infineon.com> Subject: [TF-M] Attest token v2.0 in psa-arch-tests Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi all, I was trying to run PSA arch tests for INITIAL_ATTESTATION and have some problems with them. Our platform uses version 2.0 of PSA token spec (ATTEST_TOKEN_PROFILE_PSA_2_0_0) - https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-20.txt but psa arch tests does not seem to support it. Am I correct that psa-arch-tests does not support v2.0 of attest token? If yes, then how do I select v2.0 of attest token? If no, then is there a plan to support v2.0 of attest token in psa-arch-tests? If so then what is a release date for that? 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>

2 years, 3 months

1
0
0 0

Attest token v2.0 in psa-arch-tests

by Bohdan.Hunko＠infineon.com

Hi all, I was trying to run PSA arch tests for INITIAL_ATTESTATION and have some problems with them. Our platform uses version 2.0 of PSA token spec (ATTEST_TOKEN_PROFILE_PSA_2_0_0) - https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-20.txt but psa arch tests does not seem to support it. Am I correct that psa-arch-tests does not support v2.0 of attest token? If yes, then how do I select v2.0 of attest token? If no, then is there a plan to support v2.0 of attest token in psa-arch-tests? If so then what is a release date for that? 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>

2 years, 3 months

1
1
0 0

Unable to determine default CMAKE_INSTALL_LIBDIR directory

by Quach, Brian

Hi, I'm seeing this warning when running cmake from a conan pkg: `/home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/bin/cmake -S . -B build -DTFM_PLATFORM=arm/mps2/an521`. Does anyone know how to fix it? I see the language is set by `project("Trusted Firmware M" VERSION ${TFM_VERSION} LANGUAGES C CXX ASM)`. Per-partition files done: CMake Warning (dev) at /home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/share/cmake-3.21/Modules/GNUInstallDirs.cmake:236 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs. Call Stack (most recent call first): build/lib/ext/mbedcrypto-src/CMakeLists.txt:42 (include) This warning is for project developers. Use -Wno-dev to suppress it. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

2 years, 3 months

2
1
0 0

There are many kinds

by bpqp9ny2＠nqmo.com

Car Mishaps is often harrowing experiences, leaving victims addressing physical injuries, emotional trauma, and financial burdens. In this sort of demanding occasions, owning the right lawful representation might make all the primary difference. When you are in Austin, Texas, and end up wanting legal support following a car accident, https://www.canadatopescorts.com

2 years, 3 months

1
0
0 0

STM32l562e_dk platform is excluded from LAVA tests being a blocker for TF-M builds

by Anton Komlev

Hello, STM32l562e dk platform is timing out in LAVA tests which fails all TF-M builds. The platform was excluded from tests temporarily to enable normal development progress. Best regards, Anton

2 years, 3 months

1
0
0 0

Re: STM target - HAL version upgrade?

by Tomasz Jastrzębski

Hi Ahmad, Thank you for the confirmation. To be honest, I did not expect good news. Kind regards, Tomasz From: Ahmad EL JOUAID <ahmad.eljouaid(a)st.com> Sent: Wednesday, February 7, 2024 3:04 PM To: Tomasz Jastrzębski <tdjastrzebski(a)wp.pl> Cc: tf-m-request(a)lists.trustedfirmware.org; Stephane LE ROY <stephane.leroy(a)st.com> Subject: RE: STM target - HAL version upgrade? Hi Tomasz, In our objectives, we have included the update of the STM HAL version. However, an exact date for its implementation has not been determined yet. Nevertheless, I anticipate that the timeline for its execution will not be significantly prolonged. Kind regards, Ahmad STM ST Restricted From: Tomasz Jastrzębski < <mailto:tdjastrzebski@wp.pl> tdjastrzebski(a)wp.pl> Sent: Tuesday, February 6, 2024 2:49 PM To: <mailto:tf-m@lists.trustedfirmware.org> tf-m(a)lists.trustedfirmware.org Cc: Ahmad EL JOUAID < <mailto:ahmad.eljouaid@st.com> ahmad.eljouaid(a)st.com>; Stephane LE ROY < <mailto:stephane.leroy@st.com> stephane.leroy(a)st.com> Subject: STM target - HAL version upgrade? Hi All, Are there currently any plans to update STM HAL version? HAL is a common component shared by all the STM boards. The currently used, relatively old version 1.0.0 does not support ST MCUs like STM32U5A9 and STM32U5G9 - the first one released a year ago. I need to decide where I should go ahead and do the update myself and since then probably maintain private TF-M version or maybe I should just wait because update is just on the way. Needless to say, an HAL update will probably take me way more effort than if it were done by someone who already knows the ropes. Kind regards, Tomasz Jastrzębski

2 years, 4 months

1
0
0 0

STM target - HAL version upgrade?

by Tomasz Jastrzębski

Hi All, Are there currently any plans to update STM HAL version? HAL is a common component shared by all the STM boards. The currently used, relatively old version 1.0.0 does not support ST MCUs like STM32U5A9 and STM32U5G9 - the first one released a year ago. I need to decide where I should go ahead and do the update myself and since then probably maintain private TF-M version or maybe I should just wait because update is just on the way. Needless to say, an HAL update will probably take me way more effort than if it were done by someone who already knows the ropes. Kind regards, Tomasz Jastrzębski

2 years, 4 months

2
1
0 0

STM32U585 target - how to remove TF-M and bootloader?

by Tomasz Jastrzębski

Hi All, I think I am ready to try TF-M on B-U585I-IOT02A board. However, before doing so I want to make sure I know how to remove it when tests are done. Please advise. Tomasz

2 years, 4 months

2
1
0 0

Can primary and secondary images size change in opposite directions? (2)

by Tomasz Jastrzębski

Hi Anton, I think now I finally understand what I what to achieve with TF-M and it may not be achievable. I was hoping for the TF-M to be able to be able to manage both SPE and NSPE partition containing my LocalLoader using two slots of variable size placed in non-continuous memory. The PRIMARY LocalLoader slot has fixed start while the SECONDARY LocalLoader slot has fixed end, but byte order in secondary blocks can be reversed so bootloader always knows where to start - that is, at the end of flash memory where the header starts going backwards. My MainApp remains managed by LocalLoader using Secure FW services, not by TF-M/MCUboot directly. I am afraid that the above scenario is currently not achievable with TF-M because: - LocalLoader secondary slot must have a fixed start location - The memory area that Primary/Secondary slots occupy has to be continuous - Secondary slot reverse byte order is not supported - although probably fairly easy to implement. Is my understanding correct? Kind regards, Tomasz From: Anton Komlev <Anton.Komlev(a)arm.com> Sent: Tuesday, January 30, 2024 5:32 PM To: Tomasz Jastrzębski <tdjastrzebski(a)wp.pl>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Can primary and secondary images size change in opposite directions? Hi Tomasz, If I understand you correctly, then your scenario is fully implemented on NSPE side while TF-M is essentially responsible for SPE side only, allowing any functionality of NS application as long as it stays in the memory range allocated for NSPE. Does it help? I cut the image from the original mail to stay within the size limit (80K). Best regards, Anton From: Tomasz Jastrzębski via TF-M <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> > Sent: Thursday, January 25, 2024 9:25 AM To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Can primary and secondary images size change in opposite directions? Hi All, I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. Local Loader update may result in the Main App update, but that is OK. Can primary and secondary LL images size change in opposite directions? Does TF-M support the described scenario? Image size flexibility is my goal. Kind regards, Tomasz Jastrzębski

2 years, 4 months

2
2
0 0

Re: Can primary and secondary images size change in opposite directions?

by Tomasz Jastrzębski

Hi Anton I think what I really was uncertain about was whether sizes and locations of my LocalLoader "slots" have to be hardcoded somewhere so they cannot change, but it looks like it is not the case. As you pointed out, my LocalLoader app can just use TF-M crypto service to decrypt MainApp firmware update and then decompress it on its own. Ofc, out-of-the-box TF-M decryption-decompression (same time) service would be helpful, but there are no standard ones I am aware of and by no means lack of it is any show stopper. Kind regards, Tomasz Btw, I apologize for multiple posts, I thought those exceeding 80k would be just discarded. From: Anton Komlev <Anton.Komlev(a)arm.com> Sent: Tuesday, January 30, 2024 5:23 PM To: Tomasz Jastrzębski <tdjastrzebski(a)wp.pl>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Can primary and secondary images size change in opposite directions? Hi Tomasz, If I understand you correctly, then your scenario is fully implemented on NSPE side while TF-M is essentially responsible for SPE side only, allowing any functionality of NS application as long as it stays in the memory range allocated for NSPE. Does it help? Best regards, Anton From: Tomasz Jastrzębski via TF-M <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> > Sent: Thursday, January 25, 2024 9:25 AM To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Can primary and secondary images size change in opposite directions? Hi All, I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. Local Loader update may result in the Main App update, but that is OK. Can primary and secondary LL images size change in opposite directions? Does TF-M support the described scenario? Image size flexibility is my goal. Kind regards, Tomasz Jastrzębski https://drive.google.com/file/d/17jrIfz0vE6OGJDWvXRn6TqNSh3mAX7e-/view?usp=s haring

2 years, 4 months

1
0
0 0

Re: Can primary and secondary images size change in opposite directions?

by Anton Komlev

Hi Tomasz, If I understand you correctly, then your scenario is fully implemented on NSPE side while TF-M is essentially responsible for SPE side only, allowing any functionality of NS application as long as it stays in the memory range allocated for NSPE. Does it help? I cut the image from the original mail to stay within the size limit (80K). Best regards, Anton From: Tomasz Jastrzębski via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Thursday, January 25, 2024 9:25 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Can primary and secondary images size change in opposite directions? Hi All, I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. Local Loader update may result in the Main App update, but that is OK. Can primary and secondary LL images size change in opposite directions? Does TF-M support the described scenario? Image size flexibility is my goal. Kind regards, Tomasz Jastrzębski https://drive.google.com/file/d/17jrIfz0vE6OGJDWvXRn6TqNSh3mAX7e-/view?usp=… [cid:image002.png@01DA5399.4D502290]

2 years, 4 months

1
0
0 0

Getting basics working - how to? (ST B-U585I-IOT02A, STM32U5A9/U5G9 )

by Tomasz Jastrzębski

Hello All, I read the entire TF-M documentation, but I still do not quite understand how to get started with ST B-U585I-IOT02A, although my ultimate target is STM32U5A9/U5G9 MCU (4 MB of flash, 2.5/3.0 MB SRAM). 1. Based on Getting Started <https://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.ht ml> section I managed to compile TF-M solution, but I do not know how to properly flash the board using e.g. pyOCD or OpenOCD. How do I flash bl2.bin, tfm_(n)s.bin and tfm_(n)s_signed.bin? The only method I found was described here <https://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.ht ml#run-an521-regression-sample> and it relied on Arm Development Studio, a product which after 30-day evaluation must be purchased. 2. How do I update my NS application once the device is initially provisioned? I think this, although excellent TF-M documentation, is probably aimed at those who already are familiar with TF-M and could be supplemented with some "TF-M for dummies" section, better explaining basic concepts and the purpose all the TF-M services. Anyway, my goal is to implement as simple as it gets, yet secure firmware update. Firmware has to be signed and encrypted, ideally compressed as well. Firmware must be easily upgradable by non-technical users so USB stick with firmware file on it is the method of choice. What I envision is this process: 1. user inserts USB stick 2. device enters firmware update mode - probably performed by a separate, small and updatable "USB Loader" app, optionally using basic 1bit graphics, progress bar etc. - low flash & SRAM footprint. 3. "USB Loader" loads, verifies and decrypts new firmware using TF-M APIs and compresses it (if it was not compressed) when storing it in the internal SRAM. Compression may be required since internal SRAM on STM32U5A9/U5G9 (2.3/3.0 MB) is smaller than the flash size (4 MB). 4. Once the entire new firmware is loaded into internal SRAM, "USB Loader" decompresses it block-by-block and flashes flash, I suppose, again using TF-M APIs. Does the above process make sense? It is possible to implement it with TF-M? One potential challenge I can see is that, practically speaking, my "USB Loader" must use Microsoft FileX, USBX and, in consequence, ThreadX because probably only this way I can get USB-C and exFAT partitions support in a reasonable amount of time. TF-M docs do not list Microsoft ThreadX as a supported RTOS. Kind regards, Tomasz Jastrzębski

2 years, 4 months

3
7
0 0

STM32 target provisioning difficulties

by tomasz jastrzebski.net

After successful compilation I tried to provision B-U585I-IOT02A board following the steps described here: STM32U5 provisioning<https://trustedfirmware-m.readthedocs.io/en/latest/platform/stm/common/stm3…>. Process did not succeed due to the errors described below. What am I missing? postbuild.sh results in: Thomas@AMDMINIATX MINGW64 /c/Temp/tf-m/trusted-firmware-m/platform/ext/target/stm/common/scripts (main) $ ./postbuild.sh ./postbuild.sh: line 22: /c/Temp/tf-m/trusted-firmware-m/platform/ext/target/stm/common/scripts/preprocess.sh: No such file or directory preprocess bl2 file ./postbuild.sh: line 36: preprocess: command not found C:\Python312\python.exe: can't open file 'C:\\Temp\\tf-m\\trusted-firmware-m\\platform\\ext\\target\\stm\\common\\scripts\\scripts\\stm_tool.py': [Errno 2] No such file or directory postbuild.sh failed There are 3 versions of preprocess.sh script, it is compiler specific. TFM_UPDATE.sh has some syntax errors which reveal themselves under GitBash Thomas@AMDMINIATX MINGW64 /c/Temp/tf-m/trusted-firmware-m/platform/ext/target/stm/common/scripts (main) $ ./TFM_UPDATE.sh TFM UPDATE started ./TFM_UPDATE.sh: line 52: [: ==: unary operator expected ./TFM_UPDATE.sh: line 56: [: ==: unary operator expected ./TFM_UPDATE.sh: line 59: [: ==: unary operator expected These are easy to fix. Eg. if [ $encrypted == "0x1" ]; then -> if [ "$encrypted" == "0x1" ]; then It looks postbuild.sh and TFM_UPDATE.sh take two additional parameters which are not documented. regression.sh takes one undocumented parameter.

2 years, 4 months

5
5
0 0

Can primary and secondary images have clearly different sizes?

by tomasz jastrzebski.net

Hi All, I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size, hence the latest version may be clearly larger than the previous one. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. LL1 size may be clearly different than LL2, Local Loader update may result in the Main App update, but that is OK. Does TF-M support the described scenario? Flexibility is the key. Can primary and secondary Local Loader (LL) images have clearly different sizes? Kind regards, Tomasz Jastrzębski https://drive.google.com/file/d/1n4Ihqk8S-04FlluvlveQflb5nYsXBluA/view?usp=… [cid:image001.png@01DA4F08.95319C00]<https://drive.google.com/file/d/1n4Ihqk8S-04FlluvlveQflb5nYsXBluA/view?usp=…>

2 years, 4 months

2
3
0 0

Pre-encryption image compression (re-posting as a new topic)

by Tomasz Jastrzębski

Hello All, Does the current TF-M version support image compression before image is encrypted? Needless to say, compression after the image has been encrypted would not yield reasonable compression ratio. I am showing that *.bin files, even built with MinSizeRel option, zip-compress with minimum 50% compression ratio so probably this would make sense. Tested with STM32U5 target and GCC. "PSA Certified Firmware Update API <https://arm-software.github.io/psa-api/fwu/1.0/overview/architecture.html#m anifest> " document in sections 3.1 and 3.2 provides for image compression. Kind regards, Tomasz Jastrzębski

2 years, 4 months

2
2
0 0

SFN vs IPC partition with IPC backend

by Quach, Brian

If using IPC backend, how much performance and/or memory savings is there when using SFN vs IPC partition model? I saw FF-M v1.1 recommended SFN partition model but it was not clear to me why it was preferred. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

2 years, 4 months

3
6
0 0

Getting started, ST B-U585I-IOT02A profile - compilation

by Tomasz Jastrzębski

Hi All, When I compile with GCC and Debug config (only Debug), process stops with these errors: [ 97%] Building C object bl2/CMakeFiles/bl2.dir/__/platform/ext/target/stm/common/hal/accelerator/stm .o [ 98%] Linking C executable ../bin/bl2.axf C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: address 0xc030fc4 of ../bin/bl2.axf section `.text' is not within region `FLASH' C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: ../bin/bl2.axf section `.ARM.exidx' will not fit in region `FLASH' C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: address 0xc030fc4 of ../bin/bl2.axf section `.text' is not within region `FLASH' C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: section .BL2_NoHdp_Code LMA [0c02a000,0c02a5a7] overlaps section .text LMA [0c014000,0c030fc3] C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: region `FLASH' overflowed by 28620 bytes Memory region Used Size Region Size %age Used FLASH_NVMCNT: 32 B 8 KB 0.39% FLASH: 118732 B 88 KB 131.76% FLASH_NOHDP: 1448 B 8 KB 17.68% FLASH_OTP: 756 B 4 KB 18.46% FLASH_NVM: 32 B 8 KB 0.39% RAM: 31624 B 63 KB 49.02% collect2.exe: error: ld returned 1 exit status make[5]: *** [bl2/CMakeFiles/bl2.dir/build.make:490: bin/bl2.axf] Error 1 make[4]: *** [CMakeFiles/Makefile2:1982: bl2/CMakeFiles/bl2.dir/all] Error 2 make[3]: *** [Makefile:136: all] Error 2 make[2]: *** [CMakeFiles/TF-M.dir/build.make:86: temp/src/TF-M-stamp/TF-M-build] Error 2 make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/TF-M.dir/all] Error 2 make: *** [Makefile:124: all] Error 2 Changing config to anything than Debug solves the issue, but along the way there are some warnings, of which these three seems to be particularly important: tests_reg/build_spe/build-spe/lib/ext/mbedcrypto-src/include/mbedtls/ecp.h:3 65: warning: "MBEDTLS_ECP_MAX_BYTES" redefined tests_reg/build_spe/build-spe/lib/ext/mbedcrypto-src/include/mbedtls/ecp.h:3 66: warning: "MBEDTLS_ECP_MAX_PT_LEN" redefined trusted-firmware-m/bl2/ext/mcuboot/config/mcuboot-mbedtls-cfg.h:132:2: warning: #warning "Use legacy driver API for BL2" [-Wcpp] 132 | #warning "Use legacy driver API for BL2" When I try to compile with Clang compiler latest version 6.21, I immediately get this error: C:\Temp\tf-m\tf-m-tests\tests_reg>cmake --build build_spe -- install [ 12%] Creating directories for 'TF-M' [ 25%] No download step for 'TF-M' [ 37%] No update step for 'TF-M' [ 50%] No patch step for 'TF-M' [ 62%] Performing configure step for 'TF-M' loading initial cache file C:/Temp/tf-m/tf-m-tests/tests_reg/build_spe/temp/tmp/TF-M-cache-Debug.cmake -- Found Git: C:/Program Files/Git/cmd/git.exe (found version "2.43.0.windows.1") -- The C compiler identification is unknown -- The CXX compiler identification is unknown -- The ASM compiler identification is ARMClang -- Found assembler: C:/Program Files/ArmCompilerforEmbedded6.21/bin/armasm.exe CMake Error at toolchain_ARMCLANG.cmake:190 (message): Please select newer Arm compiler version starting from 6.13. Call Stack (most recent call first): CMakeLists.txt:50 (tfm_toolchain_reload_compiler) -- Configuring incomplete, errors occurred! make[2]: *** [CMakeFiles/TF-M.dir/build.make:92: temp/src/TF-M-stamp/TF-M-configure] Error 1 make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/TF-M.dir/all] Error 2 make: *** [Makefile:124: all] Error 2 Please advise, Tomasz Jastrzębski

2 years, 4 months

2
2
0 0

Re: MemManage Fault during TF-M Secure Firmware Initialization

by Sari, Robert

Hi Jamie, thank you for the quick response! The culprit was indeed an MPU configuration that didn't comply with TF-M Isolation Level 2 requirements. Regards, Robert

2 years, 5 months

1
0
0 0

MemManage Fault during TF-M Secure Firmware Initialization

by robert.sari.ext＠siemens.com

Hello, I am currently having an issue during TF-M initialization where a MemManage fault is being triggered during secure FW initialization (most likely when the SPM is initialized). It appears to be an error during unstacking/returning from an exception as the MUNSTKERR bit of the MMFSR register is set. I receive the following exception context and exception frame when the error occurs: __________________________________________________________ FATAL ERROR: MemManage fault Here is some context for the exception: EXC_RETURN (LR): 0xFFFFFFFD Exception came from secure FW in thread mode. xPSR: 0x20000004 MSP: 0x20000BF8 PSP: 0x20002518 MSP_NS: 0x20042DF8 PSP_NS: 0xFFFFFFFC Exception frame at: 0x20002518 (Note that the exception frame may be corrupted for this type of error.) R0: 0x00000000 R1: 0x00000000 R2: 0x00000000 R3: 0x00000000 R12: 0x00000000 LR: 0xFFFFFFFE PC: 0x000358D1 xPSR: 0x01000000 CFSR: 0x00000008 BFSR: 0x00000000 BFAR: Not Valid MMFSR: 0x00000008 MMFAR: Not Valid UFSR: 0x00000000 HFSR: 0x00000000 SFSR: 0x00000000 SFAR: Not Valid __________________________________________________________ Other Information: - I am running Nordic Semiconductor's "tfm_psa_template" sample: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/nrf/samples/tfm/… - The Secure MPU is enabled (only the background region) before TF-M initialization begins - Board: nRF5340dk - TF-M Version: v1.8.0 - TF-M Isolation Level: 2 My questions are: - What part of the TF-M FW could be the cause of this MemManage fault? - Is there any way to solve this issue (such as a different TF-M configuration) so that TF-M will initialize properly? Regards, Robert Sari

2 years, 5 months

2
1
1 0

Memory Footprint Table generation

by Ruchika Gupta

Hi, With every TFM release, I see that there is a memory footprint table<https://trustedfirmware-m.readthedocs.io/en/latest/releases/2.0.0.html#refe…> which is made available for the AN521 platform. Are there any scripts available to run on the map file/other binaries to generate this table ? I would like to use the same for our platform and do some analysis. Further question- Why is there a tie up between the large profile with TFM isolation level 3 ? Is it a certification requirement ? Regards, Ruchika

2 years, 5 months

3
2
0 0

Re: Are MCUs without internal flash not supported by TF-M?

by Lee, William

Hi Antonio, Thank you for your information, it is very helpful. Best regards Tao Li (William Lee) Software Engineer @ Garmin Mobile: +8618628138760 From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Reply-To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> Date: Monday, January 1, 2024 at 06:58 To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe. Hi Torsten, you can have a look at the design document for ITS which describes encryption in ITS for a generic introduction: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/tfm/design_docs…<https://urldefense.com/v3/__https:/developer.nordicsemi.com/nRF_Connect_SDK…> A platform supports ITS_ENCRYPTION=ON if it provides an implementation of the HAL functions as follows: tfm_hal_its_aead_* For the exact list of Nordic platforms that support this option I suggest to have a look directly in the Nordic Connect SDK. Probably any platform based on the 5340 would be able to support this option, but there might be other platforms as well which you would be able to use through the SDK itself. Hope this helps. Thanks, Antonio ________________________________ From: Labs, Torsten via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Saturday, December 30, 2023 14:51 To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; Lee, William <William.Lee(a)garmin.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? Hi antonio, Thanks for those interesting news. Do you know on which Nordic platform supports encrypted ITS with TFM? Regards Torsten ________________________________ Von: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Gesendet: Saturday, December 30, 2023 9:31:10 AM An: Lee, William <William.Lee(a)garmin.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Betreff: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? Hi William, The requirement on the storage is for it to be isolated, either physically or cryptographically, as you can read from the PSA security model [1]. TF-M initially supported only the isolated model in ITS (i.e. for internal flashes) but more recently it was added support for encrypted ITS, which I believe it can be used on one of the Nordic platforms already. Hope this helps. Thanks, Antonio [1] Platform Security Model - PSA Certified https://www.psacertified.org/app/uploads/2021/12/JSADEN014_PSA_Certified_SM…<https://urldefense.com/v3/__https:/www.psacertified.org/app/uploads/2021/12…> Sent from Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/AAb9ysg__;!!EJc4YC3iFmQ!X1Zeo-qnf…> ________________________________ From: Lee, William via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Friday, December 29, 2023 5:53:50 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Are MCUs without internal flash not supported by TF-M? Hello everyone, Happy New Year! Are MCUs without internal flash not supported by TF-M? From TF-M’s documents, I saw ITS(Internal Trusted Storage) is a PSA-ROT secure service and requires store data in internal flash. Does that mean TF-M not support hardware platforms that do not have internal flash? For example, RT500 does not have internal flash: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr…<https://urldefense.com/v3/__https:/www.nxp.com/products/processors-and-micr…> Thank you! Best regards William Lee

2 years, 5 months

1
0
0 0

Re: Are MCUs without internal flash not supported by TF-M?

by Antonio De Angelis

Hi Torsten, you can have a look at the design document for ITS which describes encryption in ITS for a generic introduction: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/tfm/design_docs… A platform supports ITS_ENCRYPTION=ON if it provides an implementation of the HAL functions as follows: tfm_hal_its_aead_* For the exact list of Nordic platforms that support this option I suggest to have a look directly in the Nordic Connect SDK. Probably any platform based on the 5340 would be able to support this option, but there might be other platforms as well which you would be able to use through the SDK itself. Hope this helps. Thanks, Antonio ________________________________ From: Labs, Torsten via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Saturday, December 30, 2023 14:51 To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; Lee, William <William.Lee(a)garmin.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? Hi antonio, Thanks for those interesting news. Do you know on which Nordic platform supports encrypted ITS with TFM? Regards Torsten ________________________________ Von: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Gesendet: Saturday, December 30, 2023 9:31:10 AM An: Lee, William <William.Lee(a)garmin.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Betreff: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? Hi William, The requirement on the storage is for it to be isolated, either physically or cryptographically, as you can read from the PSA security model [1]. TF-M initially supported only the isolated model in ITS (i.e. for internal flashes) but more recently it was added support for encrypted ITS, which I believe it can be used on one of the Nordic platforms already. Hope this helps. Thanks, Antonio [1] Platform Security Model - PSA Certified https://www.psacertified.org/app/uploads/2021/12/JSADEN014_PSA_Certified_SM… Sent from Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Lee, William via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Friday, December 29, 2023 5:53:50 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Are MCUs without internal flash not supported by TF-M? Hello everyone, Happy New Year! Are MCUs without internal flash not supported by TF-M? From TF-M’s documents, I saw ITS(Internal Trusted Storage) is a PSA-ROT secure service and requires store data in internal flash. Does that mean TF-M not support hardware platforms that do not have internal flash? For example, RT500 does not have internal flash: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… Thank you! Best regards William Lee

2 years, 5 months

1
0
0 0

Are MCUs without internal flash not supported by TF-M?

by Lee, William

Hello everyone, Happy New Year! Are MCUs without internal flash not supported by TF-M? From TF-M’s documents, I saw ITS(Internal Trusted Storage) is a PSA-ROT secure service and requires store data in internal flash. Does that mean TF-M not support hardware platforms that do not have internal flash? For example, RT500 does not have internal flash: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… Thank you! Best regards William Lee

2 years, 5 months

3
2
0 0

Minor updates to the tf.org project maintenance

by Sandrine Bailleux

Hello TF-A and TF-M communities, I've done 2 minor updates to the generic tf.org project maintenance process, which TF-A and TF-M both use. Please see the pull request here: https://github.com/TrustedFirmware/tf_docs/pull/1 Please provide your feedback on the pull request, if any. Happy end-of-year celebrations to all! Best regards, Sandrine

2 years, 5 months

1
0
0 0

Arm v8 FPU questions

by Bohdan.Hunko＠infineon.com

Hi all, I have been working with FPU lately and I have a few questions regarding this topic: Looks like there are 4 use cases of FPU usage: FPU is used in Use case number SPE NSPE 1 - - 2 - + 3 + - 4 + + From https://tf-m-user-guide.trustedfirmware.org/integration_guide/tfm_fpu_suppo… my understanding is following: 1. If SPE and NSPE both does not use SPU (use case 1) then they both must be compiler with fp=soft? 2. consistent FP ABI types between SPE and NSPE must be used. So even if only one of SPE or NSPE (use cases 2 and 3) does not use FPU they both still must be compiler with fp=hard Also if both SPE and NSPE use PFU then they both must be compiler with fp=hard 3. Even if FPU is not used by NSPE, NSPE still MUST enable CP10 an CP11? - Is this correct? Is it possible to enable FPU for SPE but don't enable CP10 and CP11 in NSPE? So basically if either SPE or NSPE or both of them need to use FPU then both of them need to enable CP10 and CP11 and be compiled with fp=hard Is my understanding correct? Inline comments are welcome. 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>

2 years, 5 months

2
1
0 0

How to disable all interrupts on ARM V8?

by Bohdan.Hunko＠infineon.com

Hi all, From what I have seen, looks like __disable_irq() only disables non-secure interrupts when called from NSPE on ARM v8 arch. Am I correct? If so then how can I disable all interrupts (including secure interrupts) from NSPE? - We need this for critical section and other critical code. 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>

2 years, 5 months

2
1
0 0

Problems with integrating TF-M with RIOT OS

by Boeckmann, Lena

Hi everyone! I am currently integrating TF-M with an IoT OS (RIOT OS) and I have a few problems. I managed to build and link a secure TF-M binary and a non-secure RIOT binary and I can run some application code (print "hello world", turn LEDs on and off, etc) on the nRF9160dk. I can also use the crypto API and call psa_crypto_init. Now I have tried a few things and each of them leads to different problems, some of which I will describe in this mail hoping that someone can help me with this. I have done some debugging and have some ideas on what could be wrong, but I don't really understand how to fix the issues and don't really know how to proceed with either of them. Formatted Prints Somehow formatted prints are ignored. Calls to printf without formatting default to the stdio puts implementation and are printed without issues. Calls to printf with formatting use the implementation in tfm_sp_log_raw.c and are just ignored. They crashed at first, but I could fix that (RIOT has different implementations of the SVC ISR and I used the wrong one). Now they don't crash anymore, but are also not printed (no error output, application keeps running). Since this function is part of the secure firmware, my guess is that there's a problem with it being called from the NS world. But that should result in a SecureFault, shouldn't it? Does anyone have an idea what the issue could be? Secure memset called from NS image When calling psa_generate_key, the first step is a struct initialization: struct tfm_crypto_pack_iovec iov = { .function_id = TFM_CRYPTO_GENERATE_KEY_SID, }; This runs into a SecureFault. It turns out that during struct initialization, memset is called to zeroize the structure. This uses the memset implemented in secure_fw/shared/crt_memset.c and accesses secure RAM (between addresses 0x20015000 and 0x20016000). I found a workaround by moving the start address of NS RAM from 0x20016000 to 0x20020000. Memset now still accesses RAM before NS RAM, but does not run into a SecureFault anymore. This works for now, but I would like to find an actual fix for this. This only occurs when building with RIOT. When building the TF-M NS image and running crypto tests, memset accesses NS RAM, though I don't know if the same implementation is used. Unfortunately I don't get any debug symbols there. Could it be that a different memset implementation should be linked? Can I change it somehow? Can someone tell me which one is linked in the TF-M NS image? Crypto partition is NULL When using the workaround described above, calling psa_generate_key runs into tfm_core_panic. The stack trace here is: psa_call (tfm_psa_call.c) tfm_psa_call_pack (backend_sfn.c) tfm_spm_client_psa_call (psa_call_api.c) tfm_spm_is_ns_caller (spm_ipc.c) The problem is in tfm_spm_is_ns_caller, where struct partition_t *partition = GET_CURRENT_COMPONENT(); gets a NULL pointer. So somehow there is no crypto partition available. Of course I have enabled the crypto partition in config_base.cmake, as well as protected storage and internal trusted storage. I checked with a debugger and found out that during start up, multiple partitions are initialized and added to the global component list (stored in backend_sfn.c). Can I somehow check what types of partitions are initialized? Did anyone have a similar issue before or has any idea why the partition could be missing? Did I miss any extra steps I need to take? I know these are pretty much unrelated issues, but they are persistent and I am at a loss at how to fix them. I will take any hints and ideas, including pointers to where I can find relevant information in the docs (those have not been very helpful in these cases, but maybe I've overlooked something). Best regards, Lena

2 years, 5 months

2
2
0 0

Weird behavior of Clang linker

by Bohdan.Hunko＠infineon.com

Hi all, Our platform uses 4KBs alignment in linker files (as this is the requirement of our protection HW). For this reasons I have introduced tfm_s_linker_alignments.h. Everything works fine with GCC but we have a problem with Clang. The problem is that Clang requires LR_CODE to have same alignment as other sections inside of it. Following are the steps to reproduce the issue: 1. Set TFM_LINKER_DEFAULT_ALIGNMENT to 0x1000 in tfm_s_linker_alignments.h 2. Build AN521 with following command line cmake -S . -B build_an521 -DTFM_PLATFORM=arm/mps2/an521 -DTFM_TOOLCHAIN_FILE=./toolchain_ARMCLANG.cmake Expected result: Everything works fine Actual result: Error: L6244E: Load region LR_CODE address (0x10080400) not aligned on a 4096 byte boundary. This error is weird because there is no explicit alignment assigned to LR_CODE region. Would appreciate a help on this as it is a blocking issue for us. 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>

2 years, 5 months

3
3
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

2 years, 5 months

3
4
0 0

FIH volatile structure and stack usage

by Roman.Mazurak＠infineon.com

Hi all, I found that using FIH medium/high profile with gcc generates code that uses stack extensively. It happens because fih_int structure is marked as volatile. Is there any reason why structure itself is marked as volatile? Why it's not enough to make val and msk volatile members of fih_int structure? Best regards, Roman.

2 years, 6 months

2
4
0 0

Redundant checks in FWU code

by Bohdan.Hunko＠infineon.com

Hi all, In config/check_config.cmake there is a following code: tfm_invalid_config((MCUBOOT_UPGRADE_STRATEGY STREQUAL " DIRECT_XIP " OR MCUBOOT_UPGRADE_STRATEGY STREQUAL "RAM_LOAD") AND TFM_PARTITION_FIRMWARE_UPDATE) So looks like FWU is not supported when DIRECT_XIP or RAM_LOAD upgrade strategies are used. But then in FWU code I see a lot of checks for DIRECT_XIP or RAM_LOAD, for example in fwu_bootloader_get_image_info: #if !defined(MCUBOOT_DIRECT_XIP) && !defined(MCUBOOT_RAM_LOAD) && \ !defined(MCUBOOT_OVERWRITE_ONLY) What is the point of these checks if it is impossible to compile FWU code with DIRECT_XIP Because of check in config/check_config.cmake? 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>

2 years, 6 months

3
5
0 0

[RFC] Bump minimum CMake version required

by David Hu

Hi all, The current minimum CMake version specified in TF-M is 3.15. It is quite out-of-date. I’d like to propose to increase minimum CMake version to 3.21. CMake 3.21 can bring in some benefits, compared to CMake 3.15 * NEW behavior of several CMake policies, such as CMP0123 for Armclang. * After build split, TF-M secure build installs several build scripts. When NS build includes those build scripts, `CMAKE_CURRENT_FUNCTION_LIST_FILE/DIR` can make it easier to handle source code paths. CMake 3.21 was released 2 years ago. It should be stable enough now. May I know if you have any feedback or different opinions? Thank you. Best regards, Hu Ziji

2 years, 6 months

2
4
0 0

Reduce dependency of NS Mailbox structure on non-secure configurations

by Roman.Mazurak＠infineon.com

Hi all, I faced the problem that mailbox configuration of secure image differs from one provided for non-secure. It's because I'm using a split-build but a little bit different that is prepared for v2.0. I think we can minimize dependencies and unexpected impacts between different images when common data structures will have less customization. Currently we have three options that can change mailbox structures: 1. NUM_MAILBOX_QUEUE_SLOT - number of mailbox slots 2. TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD - defines which NS client implementation is selected. 3. TFM_MULTI_CORE_TEST - specify whether NS multi-core test suite is built. There is requirement that NUM_MAILBOX_QUEUE_SLOT must be set to 1 if NS bare metal environment is used. But this limitation is excessive. Because it's important that secure side is not using slots that are not used by non-secure side. It can be possible to use NS bare metal client even if mailbox queue size is more than one, it's just the waste of resources in such case. But it can bring a benefit that it's possible to build secure image with default settings (aka 4 mailbox slots) and there is no need to rebuild it if there will be decision to switch from RTOS to bare metal environment which can be useful for some end-user use cases. More flexible update will be to pass number of allocated slots from NS side to TF-M during initialization, it's just important to validate that number of slots doesn't not exceed maximum supported by design. TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD is another problem, because mailbox_reply_t allocates data that are not shared but used by non-secure side only. Which means that it's important to decide which NS client implementation is going to be used when TF-M is built. I see two different solutions for this problem: 1. Use union to allocate space for both of them and let decide NS client implementation which on to use. Something like this: struct mailbox_reply_t { union { //#ifdef TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD uint8_t *woken_flag; /* Indicate that owner task has been * or should be woken up, after the * reply is received. */ //#else bool is_woken; /* Indicate that owner task has been * or should be woken up, after the * reply is received. */ //#endif }; }; 1. Redesign mailbox by separating data that are used by NS client from data that are shared between cores. So, it will be much easier to update non-secure client without touching secure image. It looks like there is data needed for test suite only (nr_tx and nr_used_slots fields of ns_mailbox_queue_t) defined by TFM_MULTI_CORE_TEST. I think we can allocate it in test suite only, so there will be no need to allocate this data in shared structure and there will not be the case when location of is_full field of ns_mailbox_queue_t accessed by both cores have different location if TFM_MULTI_CORE_TEST configuration is not applied the same way for both secure and non-secure images. Regards, Roman.

2 years, 6 months

3
7
0 0

FPU flags for mbedTLS targets

by Quach, Brian

Hi, /secure_fw/partitions/crypto/CMakeLists.txt is missing passing compiler flags to mbedTLS targets which would be needed for correct FPU flags. I believe the highlighted code would be the fix: target_compile_options(${MBEDTLS_TARGET_PREFIX}mbedcrypto PRIVATE ${COMPILER_CP_FLAG} $<$<C_COMPILER_ID:GNU>:-Wno-unused-const-variable> $<$<C_COMPILER_ID:GNU>:-Wno-unused-parameter> $<$<C_COMPILER_ID:ARMClang>:-Wno-unused-const-variable> $<$<C_COMPILER_ID:ARMClang>:-Wno-unused-parameter> ) target_compile_options(${MBEDTLS_TARGET_PREFIX}p256m PRIVATE ${COMPILER_CP_FLAG} ) Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

2 years, 6 months

2
5
0 0

compile error when PS_ENCRYPTION=OFF

by Quach, Brian

Hi, if I set PS_ENCRYPTION=OFF set(PS_ENCRYPTION OFF CACHE BOOL "Enable encryption for Protected Storage partition") I see this compile error: In file included from /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/tfm_internal_trusted_storage.c:32: /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:48:31: error: 'PS_TAG_LEN_BYTES' undeclared here (not in a function) 48 | #define PS_TAG_IV_LEN_MAX ((PS_TAG_LEN_BYTES > PS_IV_LEN_BYTES) ? \ | ^~~~~~~~~~~~~~~~ /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:60:20: note: in expansion of macro 'PS_TAG_IV_LEN_MAX' 60 | uint8_t tag_iv[PS_TAG_IV_LEN_MAX]; | ^~~~~~~~~~~~~~~~~ /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:48:50: error: 'PS_IV_LEN_BYTES' undeclared here (not in a function) 48 | #define PS_TAG_IV_LEN_MAX ((PS_TAG_LEN_BYTES > PS_IV_LEN_BYTES) ? \ | ^~~~~~~~~~~~~~~ /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:60:20: note: in expansion of macro 'PS_TAG_IV_LEN_MAX' 60 | uint8_t tag_iv[PS_TAG_IV_LEN_MAX]; | ^~~~~~~~~~~~~~~~~ make[7]: *** [secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/build.make:90: secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/tfm_internal_trusted_storage.o] Error 1 I think the correct fix is to add the following highlighted code to ps_object_defs.h. Patch is attached. /*! * \struct ps_object_t * * \brief The object to be written to the file system below. Made up of the * object header and the object data. */ struct ps_object_t { struct ps_obj_header_t header; /*!< Object header */ uint8_t data[PS_MAX_OBJECT_DATA_SIZE]; /*!< Object data */ #ifdef PS_ENCRYPTION uint8_t tag_iv[PS_TAG_IV_LEN_MAX]; #endif }; Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years, 6 months

2
1
0 0

psa_call with NULL outvec causes a NULL pointer dereference

by Quach, Brian

Hi, Is it possible to call psa_call() with NULL outvecs with TF-M v2.0? I am using IPC model. This worked for me with TF-M v1.8 but now I see get a NULL pointer dereference with TF-M v2.0 when psa_reply() is called. Specifically, it happens inside update_caller_outvec_len(). It seems msg.out_size[i] is non-zero (due to a previous psa_call which had 3 outvecs). handle->caller_outvec[i].len causes a NULL pointer deference. void update_caller_outvec_len(struct connection_t *handle) { uint32_t i; for (i = 0; i < PSA_MAX_IOVEC; i++) { if (handle->msg.out_size[i] == 0) { continue; } SPM_ASSERT(handle->caller_outvec[i].base == handle->outvec_base[i]); handle->caller_outvec[i].len = handle->outvec_written[i]; } } spm_associate_call_params() does not clear msg.out_size[] so the previous contents remain. One potential fix is to add the highlighted code below to clear out_size[]. [cid:image001.png@01DA27A5.8860E6F0] Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

2 years, 6 months

2
3
0 0

Partition log write UART without validation of permissions.

by Roman.Mazurak＠infineon.com

Hi all, I noticed that partition log subsystem uses stdio_output_string through following chain of calls tfm_hal_output_sp_log => SVC TFM_SVC_OUTPUT_UNPRIV_STRING => tfm_hal_output_spm_log => stdio_output_string. SVC handler doesn't validate arguments, so it's allows APP RoT partitions to access PSA RoT memory via partition log subsystem. It seems that tfm_hal_memory_check must be called on SVC handler to validate permissions. Best Regards, Roman.

2 years, 6 months

2
1
0 0

preload.cmake

by Quach, Brian

Hi, I'm seeing references in the documentation for preload.cmake and several files with that name in TF-M v2.0.0. But looking at the code it seems like preload.cmake was replaced with cpuarch.cmake. Am I missing something? Where should be put fixed platform-specific definitions which are not related to CPU architecture? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years, 6 months

2
3
0 0

Redundant check on FWU_DEVICE_CONFIG_FILE

by Bohdan.Hunko＠infineon.com

Hi all It seems to me like following check # FWU_DEVICE_CONFIG_FILE exists and is a file if(NOT EXISTS ${FWU_DEVICE_CONFIG_FILE}) message(FATAL_ERROR "FWU_DEVICE_CONFIG_FILE:${FWU_DEVICE_CONFIG_FILE} does not exist.") elseif(IS_DIRECTORY ${FWU_DEVICE_CONFIG_FILE}) message(FATAL_ERROR "FWU_DEVICE_CONFIG_FILE:${FWU_DEVICE_CONFIG_FILE} is a folder while a file is expected.") endif() in secure_fw/partitions/firmware_update/CMakeLists.txt is redundant as FWU_DEVICE_CONFIG_FILE may be generated, thus not present when cmake performs EXISTS check (note that by default FWU_DEVICE_CONFIG_FILE is generated so I dont see point in limiting user from using generated file) So i propose to remove this check. 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>

2 years, 6 months

2
6
0 0

TF-M release v2.0.0 announcement

by Anton Komlev

Hello, I am happy to announce the new release of TF-M v2.0.0<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv2.0…>. The major version update indicates the important changes in the way TF-M builds. New major features are: * TF-M secure build process and non-secure build process are split. * Refer to TF-M Build Instruction to build SPE image. * Refer to Building Tests to build non-secure tests. * Update new Mailbox agent API. * Decouple the specific application Mailbox from SPM, make it an application in Secure Partition. * Unify the interfaces between partitions and SPM, and reduces the interaction interface between them. * Multi-core support in the Secure Function (SFN) model. * Optimize SPM critical section implementation to reduce time cost in isolation level 2&3. * Use local variables for connection handles instead of dynamic allocation. * P256-M component is enabled on the TF-M side in profile medium. * MCUboot upgrade to v2.0.0. * Mbed TLS upgrade to v3.5.0. * TF-M PSA client API performance profiling is tracked in SQUAD and the profiling tool is updated. * TF-M integrates Read the Docs. Please check the release notes<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/25143/12/doc…> for more information. The release branch changes will be ported to the main branch shortly. Many thanks to everyone for contributing, reviewing and supporting this milestone. Anton

2 years, 6 months

2
1
0 0

Deprecate Laird Connectivity platform

by Andersson, Joakim

The Laird Connectivity platform board BL5340 DVK no longer compiles in the main branch of TF-M after the split build feature was merged. The BL5340 DVK is a module that contains the nRF5340 SoC, because of this the platform is re-using the Nordic platform support files. This cross-reference is causing us, the maintainers of Nordic a lot of problems as making changes to the Nordic platform code can break the Laird Connectivity platform. We don't have this board either to run any tests and confirm any changes. Laird Connectivity has not contributed to the platform support for more than a year. Nordics strategy for maintaining support for TF-M is to have the base DK supported in TF-M for testing purposes, and then provide support for all other boards in our SDK through our board support configuration system. Removing the platform from TF-M will still mean that the BL5340 DVK board is supported in the nRF Connect SDK. To support the board in the Zephyr Project the following PR is needed: https://github.com/zephyrproject-rtos/zephyr/pull/65823 Joakim Andersson Nordic Semiconductor

2 years, 6 months

1
0
0 0

How can use Mailbox in TF-M on Dual-core System ?

by 진국 박

hello. I have ported corestone1000 plaform to tfm and am trying to use mhu to send and receive messages between secure enclave (SPE)core and host core(NSPE). (I want to use it for future encryption requests). Looking at the rss platform and corstone-1000 tfm code, the function for initializing and registering the mhu seems to be tfm_inter_core_comm_init. But I can't find the part that calls tfm_inter_core_comm_init. Can anyone tell me the procedure and a simple example of sending and receiving messages using MHU in a TFM environment? I've been looking through the TFM documentation, but I can't find it yet. Below is the tfm_inter_core_comm_init function to register the rpc of the spe in rss. I was wondering where the function below is called and used. int32_t tfm_inter_core_comm_init(void) { int int32_t ret; /* Register RPC callbacks */ ret = tfm_rpc_register_ops(&rpc_ops); if (ret != TFM_RPC_SUCCESS) { return ret; } /* Platform specific initialization */ ret = tfm_multi_core_hal_init(); if (ret != TFM_PLAT_ERR_SUCCESS) { tfm_rpc_unregister_ops(); return ret; } } return TFM_RPC_SUCCESS; } You are a newbie to TFM and are looking for help.

2 years, 6 months

3
3
0 0

Flashing problems on B-U585I-IOT02A

by João Bento

Hello, I have recently trying to flash the B-U585I-IOT02A board by running the 3 scripts generated in the build folder, as I usually do with the STM32L552 board. However, I encountered some unexpected errors as I noticed that the secure and non-secure images were being written to external flash address spaces. I quickly noticed that this was happening because the "flash_layout.h" file defines the variable "EXTERNAL_FLASH". Additionally, the "image_macros_to_preprocess_bl2.c" set the image as encrypted by default with "RE_IMAGE_ENCRYPTED= 0X01", causing the "TFM_UPDATE.sh" script to write to the secondary slots. I found it quite strange because tf-m presented an off-the-shelf solution for the other board while for this board it assumes the use of an external flash. Nevertheless, I tried to work around these limitations by commenting the EXTERNAL_FLASH variable and assigning the "RE_IMAGE_ENCRYPTED= 0X00" similarly to the stm32l552. This led to the images being written to the primary slots defined in the flash layout, however, in runtime I encountered an error that states "Unable to find bootable image". Therefore, my question is: Do I need to make further adjustments, or is it possible that there's a configuration issue that is not compatible with the board? Best regards, João Bento

2 years, 6 months

2
4
0 0

Start of TF-M v2.0.0 release

by Anton Komlev

Hello, The branch release/2.0.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=release/…> has been created indicating the start of the release process and features freeze. RC1 tag will follow after a successful run of the basic tests. Let me remind that the code is not frozen, and development can be continued on the main branch as described in TF-M Release Process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Thanks, Anton

2 years, 6 months

1
2
0 0

PSA_FRAMEWORK_HAS_MM_IOVEC

by Quach, Brian

Hi, I saw that PSA_FRAMEWORK_HAS_MM_IOVEC is not permitted for Isolation level 2-3 and transient copies of the input and output data into a 5KB scratch buffer are always made when making a PSA call. This makes sense as FF-Mv1.1 states: “In a system using isolation level 3, a Secure Partitions is not permitted to access another Secure Partition’s Private data. MM-IOVEC can provide a mechanism for one Secure Partition to access the other’s Private data.” But I think the requirements for isolation level 3 could be fulfilled by: If SP detects a Secure caller, it could make a transient copy of I/O data. If SP detects a Non-Secure caller, it could use MMIOVECs or a similar method to access NS memory directly to avoid overhead and limitations of copying the I/O data. Is this logical/ correct? With this approach, an attacker may tamper NS input data while the RoT service is processing those data but rules of isolation level 3 are maintained. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years, 6 months

2
3
0 0

Various issues in successfully using GDB to debug secure apps on Musca S1 connected over USB DAPLink to a Linux host

by Arun D

Now sure where exactly this belongs, but I already posted question abut the Musca S1 earlier, and this seems relevant. ARM support essentially seem to tell me that they cannot support GDB and they are not certain of DAPLink, and recommend ULINKPLUS debugger with ARM IDE. So wanted to get a sense from anyone who has attempted to use this. In the following I describe the steps to obtain a base line, then provide description in what way GDB / DAPLink seems to misbehave. To get a base line: ~~~~~~~~~~~~~ - I build 'samples/hello_world' app using Zephyr 'v3.4.0'. Copy the 'build/zephyr/zephyr.hex' file to '/media/user/MUSCA_S1' directory when the board is USB. Connect a terminal emulator to the UART exposed by USB DAPLink, e.g. 'picocom -b 115200 -y n /dev/ttyACM0'. I can see on the console the followinbg *** Booting Zephyr OS build zephyr-v3.4.0 *** Hello World! musca_s1 If I press the reset button, the app restarts as well. This is as expected. I note that this is entirely running as in secure mode, that it does not use TF-M. - Next I start 'pyocd-gdbserver'. Then start a GDB session using the 'zephyr.elf' file, 'target remote localhost:3333' to connect it to the gdbserver. It connects ok. So I put a breakpoint at "main", do a 'monitor reset halt', and then continue. The breakpoint at 'main' is hit, I can obtain the backtrace to see it is correct as expected. So my setup seems good. Next I attempt to test a non-secure app with TF-M. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Build the app using Zephyr build env 'west build -b v2m_musca_s1_ns samples/tfm_integration/tfm_psa_test/ -DCONFIG_TFM_PSA_TEST_CRYPTO=y'. Copy 'build/zephyr/tfm_merged.hex' to '/media/user/MUSCA_S1'. Connect a terminal emulator, picocom, to the console, and hit the PBON (power on) button. I see the following output as expected on the console: Musca-S1 Dual Firmware Version 1.9 [WRN] This device was provisioned with dummy keys. This device is NOT SECURE [Sec Thread] Secure image initializing! Booting TF-M 79a6115d3 [INF][Crypto] Initialising HW accelerator... complete. *** Booting Zephyr OS build zephyr-v3.4.0 *** ***** PSA Architecture Test Suite - Version 1.4 ***** Running.. Crypto Suite ****************************************** TEST: 201 | DESCRIPTION: Testing crypto key management APIs | UT: psa_crypto_init [Info] Executing tests from non-secure This is as expected. However, if I press the reset button the board does not appear to reset - this is unexpected. Has anyone seen a different behavior? Is the specific board that I have is misbehaving? - Now I start PyOCD GDB server, start GDB and successfully connect it to the GDB server. The target is halted where it was executing, e.g. Remote debugging using localhost:3333 CC_HalWaitInterruptRND (data=data@entry=1024) at /home/zephyr/zephyrproject/modules/tee/tf-m/trusted-firmware-m/lib/ext/cryptocell-312-runtime/host/src/hal/cc3x/cc_hal.c:107 107 irr = CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_IRR)); (gdb) This is as expected. - Next I put a breakpoint at 'sprt_main', then issue a 'monitor reset halt', then issue a 'continue', The breakpoint is is NOT hit. I see a blue LED blink at perhaps 4 times per second. This is unexpected. Has anyone seen this behave correctly? Do I have a board that is misbehaving?

2 years, 7 months

4
10
2 0

Building TF-M for ARM reference SoC/boards MPS2/MPS3 and Musca S1

by capablegh＠gmail.com

Hello. The ARM MPS2/MPS3 have Cortex M33 two processor configuration. I am building TF-M under the Zephyr OS setup. From the build it appears that the secure (TF-M) and non-secure (Zephyr OS and app) are bound and executed on separate CPUs. Assuming that two CPUs are used, in the build, is there a way to force using same one CPU for TF-M and Zephyr/app, while disabling the second CPU? Thanks.

2 years, 7 months

5
12
1 0

Increasing the flash partition for the Secure Firmware in TF-M for MPS2-AN521 board emulated using Qemu

by Gowri Ramshankar

Problem: ARoT app is too large, that the image build fails. Error: /home/gramshan/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: bin/tfm_s.axf section `.ER_UNPRIV_CODE' will not fit in region `FLASH' /home/gramshan/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: region `FLASH' overflowed by 114956 bytes Memory region Used Size Region Size %age Used FLASH: 572684 B 447 KB 125.11% RAM: 54556 B 1 MB 5.20% To overcome this issue, I changed the flash_layout header file (https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/platfo…) such that the secure side size is (FLASH_S_PARTITION_SIZE) 700+KB from the 512KB default for the MPS2 AN521 app, and correspondingly update the non-secure side FLASH_NS_PARTITION_SIZEto be 300KB. This builds the tfm_merged.hex file, But fails it to boot the app. So, I do not use your ARoT, but just built as non-secure app - the 'hello_world' Zephyr app that prints a one line hello_world on the console, but using the modified partition layout. This too fails to boot, in that the "hello world" is not printed. I debugged this to find that it is BL2 that is failing. I see that the Panic occurs during the image swapping operation, this is because the image to be filled in the primary slot is identified as invalid and the secure boot stops. The TF-M thinks some firmware upgrade is happening, the integrity check fails and panics, thus inducing a Fault Injection Hardening defense. Now I am stuck with this issue and I do not know how to proceed further, any help on how to change the flash partition sizes in a clean manner would be appreciated.

2 years, 7 months

3
5
0 0

Scheduling bug

by Bohdan.Hunko＠infineon.com

Hi There seem to be scheduling bug we have found in SPM. This bug is related to handling of interrupts that arrives during SVC call and assert signed for partition. Steps to reproduce: 1. Call psa_wait() from partition (e.g. mailbox partition) 2. During execution of SVC handler generate Interrupt that asserts signal of that partition (e.g. mailbox partition signal ) (adding long delay in SVC handler or adding breakpoint in SVC handler helps to easier reproduce this ) 3. Following sequence happens: * Mailbox IRQ has lower priority than SVC thus SVC is not preempted. * SVC sees that mailbox partition is blocked (as it is waiting for signal and no signals are pending) * SVC triggers pendSV i. Mailbox IRQ and pendSV are both pending * Mailbox IRQ has higher priority than pendSV thus Mailbox IRQ is executed * Mailbox IRQ calls spm_handle_interrupt i. Signal is asserted thus spm_handle_interrupt in thrd_next calls query_state_cb which returns THRD_STATE_RET_VAL_AVAIL and thus tfm_arch_set_context_ret_code is called ii. tfm_arch_set_context_ret_code sets return code using OLD value of partition PSP (as it was never updated, as it is updated in PendSV) * Mailbox IRQ return, pendsv is started and it runs mailbox partition i. Mailbox partition has 0 as signal because return value was written to wrong location is stack Patch I have attached to the mail solves this problem for us BUT it seems more like a workaround than a proper fix( Anyways it would be nice to have this problem review by SPM experts and have proper fix (maybe we have other places with same problem...) 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>

2 years, 7 months

2
2
0 0

Merging build split feature branch back to main branch

by David Hu

Hi, I’d like to give you a heads-up that build split feature branch will be merged back to main branch very soon this week. Trusted-firmware-m build split branch: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/?h=feature… Tf-m-tests build split branch: https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/?h=feature-build-s… Build split feature improves how NS side integrate with TF-M SPE and therefore build commands are changed for building regression tests and PSA arch tests. Could you please refer to https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/23898 for updated commands/configuration to integrate NS side and port platforms after build split? If anything is broken after build split, please let us know. It would be also appreciated if you could contribute to build split. 😊 Any feedback or comment is welcome. Best regards, Hu Ziji

2 years, 7 months

1
1
0 0

How is Secure Enclave configured?

by Sunguk Bin

I have a few questions regarding RSS and Secure Enclave to see what's required and considered for SoC design to leverage RSS and why we nee to use RSS & TF-M 1. What is the difference between RSS and Secure Enclave? - Is RSS the same as Secure Enclave? - Or is it referring to any subsystem providing runtime crypto service regardless of whether it's a Secure Enclave or not? Question below is assuming RSS is a Secure Enclave...... 2. What enables TF-M to operate as a Secure Enclave? - To operate as a Secure Enclave, HW support is mandatory? a) If so, we must use a Secure Enclave IP such as cryptoisland(CI-300P-C)? b) Or can we construct a Secure Enclave with some other IPs(LCM, KMU, CryptoCell) metioned RSS doc? (by using TF-M without secure enclave IP) It feels vague whether this can be called a Secure Enclave... https://tf-m-user-guide.trustedfirmware.org/platform/arm/rss/rss_key_manage… - If HW support is not mandatory, I wonder how TF-M can operate as a Secure Enclave. - The article below seems to say that TF-M can provide Secure Enclave functionality without HW support. or I may misunderstand. https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/tfm/technical_re…

2 years, 7 months

2
5
0 0

Non-secure client id management

by Chris.Brand＠infineon.com

Hi, Reading through https://tf-m-user-guide.trustedfirmware.org/integration_guide/non-secure_cl… I'm wondering why so much of the work is done in the secure world. Ultimately, the secure world relies on the non-secure world to tell it the client_id, directly or indirectly. Is there a good reason for the NCSE part to reside in the secure world, rather than the non-secure? Particularly as the document states that the non-secure RTOS may have a built-in "Secure Context Manager", there may well be redundancy between that and NCSE that could be eliminated if the NCSE was in the NSPE. And the less code there is in the secure world, the less scope for vulnerabilities. If client_ids themselves were passed from the NS to the S world, it would probably be very easy to use that same interface on the NS core in a dual core system, too. Chris

2 years, 7 months

2
1
0 0

Bool cast is wrong in Corestone cmake file

by Bohdan.Hunko＠infineon.com

Hi, Seems like following code $<$<BOOL:TFM_PARTITION_PLATFORM>:${CMAKE_CURRENT_SOURCE_DIR}/services/src/tfm_platform_system.c> In platform/ext/target/arm/corstone1000/CMakeLists.txt is wrong because it uses TFM_PARTITION_PLATFORM but should use ${ TFM_PARTITION_PLATFORM } If so then maybe platform maintainers can fix this. 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>

2 years, 7 months

1
0
0 0

Recommended GNU compiler version

by Quach, Brian

Is 11.2-2022.02 the recommended compiler version? I saw TF-M v1.8 states: " GNU Arm compiler version *10-2020-q4-major* has an issue in CMSE support. The bug is reported in `here <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157>`__. Select other GNU Arm compiler versions instead. GNU Arm compiler version greater and equal than *11.3.Rel1* has a linker issue in syscall. Select other GNU Arm compiler versions instead. " Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years, 7 months

3
8
0 0

gateway attribute question

by Quach, Brian

Hi, When is it appropriate to use "__tz_c_veneer" vs. "__tfm_nspm_secure_gateway_attributes__"? The only difference appears to be placing it in "SFN" section. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years, 8 months

2
1
0 0

Build error with customized mbedcrypto configuration

by S Krishnan, Archanaa

Hello, I am trying to build TF-M v1.8 with a custom tfm_mbedcrypto_config_profile_medium.h . I mainly do not want to use a platform specific calloc /free calls, instead use standard free() and calloc(). If I disable MBEDTLS_PLATFORM_MEMORY and MBEDTLS_PLATFORM_C in tfm_mbedcrypto_config_profile_medium.h and attempt to build TF-M, I get the following error: /arm-none-eabi/lib/thumb/v8-m.main+fp/hard/libnosys.a(sbrk.o): in function `_sbrk': /data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/libgloss/libnosys/sbrk.c:21: undefined reference to `end' I'm able to build mbedtls package with both MBEDTLS_PLATFORM_MEMORY and MBEDTLS_PLATFORM_C disabled without any errors, the undefined reference error is only seen when building TF-M. Any thoughts on how to resolve this? Regards, Archanaa

2 years, 8 months

4
10
0 0

Dependency on generated files is broken

by Bohdan.Hunko＠infineon.com

Hi all, Seems like dependency on generated files is broken. Steps to reproduce: 1. Build any platform at any mode 2. Change any .template file 3. Expected result: 1. New file is generated from the updated .template file Actual result: 1. Generated files step is skipped. My best guess will be that 1ce59292a47b1316e5d8b4d28bcaf9d8e2bdc0a5 broke it. Could this be fixed? 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>

2 years, 8 months

4
10
0 0

Rename TF-M branches master -> main

by Anton Komlev

Hello, Some time ago we planned to rename our master branch to main in all 6 repositories. There are multiple ways of doing that and I want to discuss with the community the best way suitable for all. I can see the following options: 1. rename master->main and use the main from one day. 2. Create the main for contribution with main->master sync. Make master R/O and delete it in 3 months. 3. Keep contributing to the master but syncing master->main. 4. Other way? I suggest option 2 but looking for better alternatives if any. Thanks, Anton

2 years, 8 months

4
6
0 0

Mailbox agent API doc update - should be the final round

by Ken Liu

Hi everyone, The mailbox ns agent update document has the latest update to solidarize the API, here is the link for your review: Docs: Mailbox non-secure vectors processing (Ie4ec599c) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/22282> The agent-specific API should be good enough for now to handle different mailbox implementation cases, such as memory-based or non-memory-based. * Non-secure provided vectors can be referenced directly to avoid extra copy. * For non-memory-based schemes, the vectors have to be collected locally in NS Agent. We are also updating the code to validate the new API, may touch those platforms that are mailbox-related, please take care of the patches as well. SPM: Update the agent API to follow the design (I38e67578) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/22608/2> BR /Ken

2 years, 8 months

1
0
0 0

New TrustedFirmware Discord Server

by Don Harbin

Hi All, Note you may have received another instance of this note but when I attempted to send to all TF ML's simultaneously it seemed to fail, so sending to each one at a time. Sorry about that. :/ We've created a Discord Server for real time chats/sharing. This solution comes at no cost to the project, is set up with channels for each project, includes a #general channel, and supports direct 1-1 chats between members, all with the goal of improving collaboration between trustedfirmware.org developers. We encourage all to join! :) Instructions for joining can be found on the TF.org FAQ page <https://www.trustedfirmware.org/faq/>. See you all there and please don't hesitate to reach out if you have any questions! Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 9 months

1
0
0 0

New TrustedFirmware Discord Server

by don.harbin＠linaro.org

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

2 years, 9 months

1
0
0 0

Announcing TF-Mv1.8.1 fix

by Anton Komlev

Hi, TF-M released a hotfix to the current version, tagged by TF-Mv1.8.1<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.8…> The fixes: * Partial tag comparison when using Chacha20-Poly1305 on the PSA driver API interface in CryptoCell enabled platforms. Registered as CVE-2023-40271, Please check the related advisory TFMV-6: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/secur… Thanks, Anton

2 years, 9 months

1
0
0 0

Updated invitation: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday (BST) (tf-m@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated TF-M Tech forum Every 4 weeks from 8am to 9am on Thursday United Kingdom Time Location https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9253579… 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/==…Topic: TF-M Tech forum - Asia Time Zone FriendlyTime: Nov 12, 2020 07:00 AM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 4, 2021, 5 occurrence(s)        Nov 12, 2020 07:00 AM        Dec 10, 2020 07:00 AM        Jan 7, 2021 07:00 AM        Feb 4, 2021 07:00 AM        Mar 4, 2021 07:00 AMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT09Meeting ID: 925 3579 4925Passcode: 414410One tap mobile+12532158782,,92535794925# US (Tacoma)+13462487799,,92535794925# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 925 3579 4925Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW Guests Don Harbin - creator tf-m(a)lists.trustedfirmware.org anton.komlev(a)arm.com leonardo.sandoval(a)linaro.org abdelmalek.omar1(a)gmail.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Reply for tf-m(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 9 months

1
0
0 0

Updated invitation: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday (BST) (tf-m@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated TF-M Tech forum Every 4 weeks from 8am to 9am on Thursday United Kingdom Time Location https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9253579… 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/==…Topic: TF-M Tech forum - Asia Time Zone FriendlyTime: Nov 12, 2020 07:00 AM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 4, 2021, 5 occurrence(s)        Nov 12, 2020 07:00 AM        Dec 10, 2020 07:00 AM        Jan 7, 2021 07:00 AM        Feb 4, 2021 07:00 AM        Mar 4, 2021 07:00 AMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT09Meeting ID: 925 3579 4925Passcode: 414410One tap mobile+12532158782,,92535794925# US (Tacoma)+13462487799,,92535794925# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 925 3579 4925Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW Guests Don Harbin - creator tf-m(a)lists.trustedfirmware.org anton.komlev(a)arm.com leonardo.sandoval(a)linaro.org abdelmalek.omar1(a)gmail.com joanna.farley(a)arm.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Reply for tf-m(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=aDM1OHZtbG0wa2di… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 9 months

1
0
0 0

Updated invitation: TF-M Tech forum @ Every 4 weeks from 3pm to 4pm on Thursday from Thu Jan 20, 2022 to Thu Aug 31 (GMT) (tf-m@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: time TF-M Tech forum Every 4 weeks from 3pm to 4pm on Thursday from Thursday Jan 20, 2022 to Thursday Aug 31 United Kingdom Time Location https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9557079… 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/==… Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 18, 2021, 6 occurrence(s)        Oct 29, 2020 03:00 PM        Nov 26, 2020 03:00 PM        Dec 24, 2020 03:00 PM        Jan 21, 2021 03:00 PM        Feb 18, 2021 03:00 PM        Mar 18, 2021 03:00 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742# US (Tacoma)+13462487799,,95570795742# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number: https://linaro-org.zoom.us/u/abx3I7IoRq Guests Don Harbin - creator anton.komlev(a)arm.com abdelmalek.omar1(a)gmail.com kevin.townsend(a)linaro.org seth(a)nxmlabs.com leonardo.sandoval(a)linaro.org tf-m(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=djczYWZqa3ZmMW5n… Reply for tf-m(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=djczYWZqa3ZmMW5n… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 9 months

1
0
0 0

Updated invitation: TF-M Tech forum @ Every 4 weeks from 4pm to 5pm on Thursday (BST) (tf-m@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated TF-M Tech forum Every 4 weeks from 4pm to 5pm on Thursday United Kingdom Time Location https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9557079… 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/==… Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 18, 2021, 6 occurrence(s)        Oct 29, 2020 03:00 PM        Nov 26, 2020 03:00 PM        Dec 24, 2020 03:00 PM        Jan 21, 2021 03:00 PM        Feb 18, 2021 03:00 PM        Mar 18, 2021 03:00 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742# US (Tacoma)+13462487799,,95570795742# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number: https://linaro-org.zoom.us/u/abx3I7IoRq Guests Don Harbin - creator anton.komlev(a)arm.com abdelmalek.omar1(a)gmail.com kevin.townsend(a)linaro.org seth(a)nxmlabs.com leonardo.sandoval(a)linaro.org tf-m(a)lists.trustedfirmware.org joanna.farley(a)arm.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=djczYWZqa3ZmMW5n… Reply for tf-m(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=djczYWZqa3ZmMW5n… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 9 months

1
0
0 0

CRYPTO_BUILTIN_KEYS

by Quach, Brian

Hi, I see "CRYPTO_TFM_BUILTIN_KEYS_DRIVER" mentioned in the documentation but where is "CRYPTO_BUILTIN_KEYS" defined? And should those target props be formatted as "${prop}"? target_compile_definitions(tfm_psa_rot_partition_crypto PUBLIC MBEDTLS_PSA_CRYPTO_DRIVERS MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS $<$<BOOL:CRYPTO_BUILTIN_KEYS>:PSA_CRYPTO_DRIVER_TFM_BUILTIN_KEY> PRIVATE $<$<STREQUAL:${CRYPTO_HW_ACCELERATOR_TYPE},cc312>:CRYPTO_HW_ACCELERATOR_CC312> MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER ) https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/… Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years, 9 months

2
2
0 0

PSA Crypto headers for v8-M TrustZone Solution - feedback gathering

by Antonio De Angelis

Hi all, following up on the presentation I gave on last tech forum (https://www.trustedfirmware.org/docs/PSACryptoHeader_June23_Antonio_shareab…) and related discussion (https://linaro-org.zoom.us/rec/share/1bBb9d06OWPACMtT_wC6C336k2Y0oeAtbM5REG… , passcode: *%RuR8Q8), I'd like to start this thread to collect feedback on TF-M's current solution as a candidate for this effort. TF-M's headers: psa « include « interface - trusted-firmware-m.git - Trusted Firmware for M profile Arm CPUs<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/interface/…> I plan to discuss the feedback received in one of the coming tech-forums (but likely not next week's). Thanks, Antonio

2 years, 10 months

2
1
0 0

S/MIME email certificate usage in Mbed TLS library

by nagarajan.rak＠gmail.com

Our requirement is to send email securely from our embedded device running on STM32H7 processor. There's an SMTP client application (implemented using Mbed TLS library) running on this device, which will send emails to the recipient via custom/public email server such as smtp.gmail.com. We are planning to use S/MIME email certificate from the one of the Trusted CA, for encryption of the email message and authentication of the client/server. We learnt that each S/MIME email certificate support only one email address, but we will be having multiple devices running on the field and each device will have unique email address from which email will be sent. Getting S/MIME email certificate for device will not be feasible, is there any better way we can handle this scenario effectively. Your response to this problem is greatly appreciated. Thank you, Nagaraj

2 years, 10 months

2
1
0 0

Hybrid platforms discussion follow up.

by Anton Komlev

Hi, On the last tech forum (June 22) we started discussion on multicore hybrid platforms. By this mail I’d like to follow up and continue offline analyses on new use-cases and requirements for TF-M design update. The recorded session is available here: https://linaro-org.zoom.us/rec/share/yseF-mYwUTtHHPkQJQO6IEv72xCd0Lz1pQQecc…, Passcode: 5s=Npv=w and slides: https://www.trustedfirmware.org/docs/tech_forum_20230622_Hybrid_platforms.p… The current plan is to take time, think on the use-cases and map them on requirements. With more thought and materials, we will have another session about September time to define our needs in the support of new type of platform. Please share your thoughts in reply. Thanks, Anton

2 years, 10 months

3
3
0 0

Design update: Choose ABI for partition interfaces by checking boundaries

by Xinyu Zhang

Hi, We are planning to update the mechanism on partition interface ABI selection in IPC model. In current Implementation, cross call ABI is chosen in Isolation Level 1, and SVC call ABI is chosen in Isolation Level 2&3. However, interfaces are actually the bridge between SPM and caller partitions. If one partition shares the same boundary with SPM, cross call ABI is the choice; while if one partition does not share the same boundary with SPM, a SVC ABI is the proper choice. But, a simple comparison between two boundary values cannot be used for checking if the two boundaries are the same one - these values might be encoded with bit fields and contains more info than memory regions. Hence the comparison should be done by who generated them - the isolation HAL implementation in platform sources. So here comes to the following design: 1. In HAL function tfm_hal_bind_boundary, encode p_ldinf into boundary value, so that there is no need to pass both p_ldinf and boundary value to switch boundary. 1. Implement a HAL function to compare boundaries and switch boundary if needed. tfm_hal_status_t tfm_hal_switch_boundary( uintptr_t target_boundary, uintptr _t current_boundary, uint32_t compare_only, /* 0: Switch boundary if they are different, 1: Only compare whether the boundaries are different and do not switch */ uint32_t* compare_result); /* Tell the caller whether the boundaries are different */ 1. Select correct type of ABI when processing metadata of partition based on boundary. void prv_process_metadata(struct partition_t *p_pt) { ... tfm_hal_switch_boundary(SPM_BOUNDARY, p_pt->boundary, 1, *compare_result); if (compare_result == 1) { p_rt_meta->psa_fns = &psa_api_svc; } else { p_rt_meta->psa_fns = &psa_api_cross; } ... } Please let us know if you have any suggestion. Thanks, Xinyu

2 years, 10 months

1
0
0 0

FYI: Session on OpenCI and MISRA

by Don Harbin

Hi All, I wanted to let you know that next Thursday, July 27th, the TF-A Tech Forum will be hosting a presentation on OpenCI and MISRA presented by Paul Sokolovski of Linaro and Roberto Bagnara from Bugseng. MISRA is being enabled on both TF-A and TF-M in OpenCI, so sending this out to both lists since users in both domains may be interested in the session. Meeting time and dial up info can be found in the TF community calendar located here: https://www.trustedfirmware.org/meetings/ Best Regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 10 months

1
0
0 0

Why client API is built with tfm_sprt target?

by Roman.Mazurak＠infineon.com

Hi all, I'm wondering why client API is build with tfm_sprt target (Secure Partition Runtime Library)? Client API is used by non-secure clients and secure clients. It means that static library is built once, but used with two different images. And it's expected that such images can use different types of cores, compilation settings, etc... Probably it make sense to build this target in scope of psa_interface. Regards, Roman.

2 years, 11 months

3
3
0 0

mbedtls_platform_setup/teardown in TF-M ?

by Rehan Malak

Dear TF-M developers, I am currently adapting a basic MbedTLS / PSA Crypto example such that it would run on the NS side with TF-M doing the crypto. At the end, this is very similar to this psa_sign_verify_message_test from the NS crypto test suite : https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/sui… But my build config of MbedTLS has MBEDTLS_PLATFORM_SETUP_TEARDOWN_ALT enabled because I have a custom mbedtls_platform_setup / mbedtls_platform_teardown. And I can't see any place in TF-M where mbedtls_platform_setup/mbedtls_platform_teardown are called : ? -> mbedtls_platform_setup ? -> mbedtls_platform_teardown At first, I tried to put this code into the psa_driver_wrapper_init/psa_driver_wrapper_free but I have a similar problem : tfm_crypto_engine_init -> psa_crypto_init -> psa_driver_wrapper_init ? -> mbedtls_psa_crypto_free -> psa_driver_wrapper_free Is there any cmake/Kconfig option or any C macros to hook TF-M initialization/shutdown with mbedtls_platform_setup/mbedtls_platform_teardown without patching TF-M ? If not, could mbedtls_platform_setup be called here ? https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/… or is there a nicer way of doing this ? (btw, I am currently experimenting on qemu mps2-an521) Thanks for any advice ! 🙂 Best regards, Rehan MALAK Intrinsic ID

2 years, 11 months

4
4
0 0

Configuration order

by Roman.Mazurak＠infineon.com

Hi Andrey, Patch 21339<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/21339> introduced changes of configuration order: 1. Platform configuration via TARGET_CONFIG_HEADER_FILE. 2. Project configuration via PROJECT_CONFIG_HEADER_FILE 3. config_base.h It means that target can't change configuration that is expected to be changed by project. Example: 1. Platform must redefine ITS_STACK_SIZE to satisfy driver requirements. The good way for this is to set ITS_STACK_SIZE in config_tfm_target.h. 2. Project developer need to perform some additional debugging or profiling of the product, so the TF-M must be built with extra code that require additional stack size. It means that project developer need to #undef ITS_STACK_SIZE and then redefine it using #define ITS_STACK_SIZE. But this #undef/#define approach is not safe, because it's possible to calculate some other settings using configuration variable in config_tfm_target.h or perform additional configuration validation by config_tfm_target.h. It looks like the new changes created another bunch of problems for TF-M configuration. Regards, Roman.

2 years, 11 months

2
1
0 0

Fwd: [Tf-openci-triage] FYI; Cambridge Lab Down

by Don Harbin

FYI to all TF dev teams leveraging Open CI. Best regards, Don ---------- Forwarded message --------- From: Glen Valante via Tf-openci-triage < tf-openci-triage(a)lists.trustedfirmware.org> Date: Fri, 23 Jun 2023 at 08:41 Subject: [Tf-openci-triage] FYI; Cambridge Lab Down To: tf-openci-triage(a)lists.trustedfirmware.org < tf-openci-triage(a)lists.trustedfirmware.org> Hello All; FYI; the Cambridge lab took a serious power hit and is down. They are scrambling to get things back up, but it may take all weekend. Expect LAVA failures and other strange results. Thanks; -g -- [image: Linaro] <http://www.linaro.org> Glen Valante | *Director Program & Project Management* T: +1.508.517.3461 <1617-320-5000> glen.valante(a)linaro.org | Skype: gvalante <callto:gvalante> -- Tf-openci-triage mailing list -- tf-openci-triage(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-triage-leave(a)lists.trustedfirmware.org

2 years, 11 months

1
0
0 0

ST support for secure peripheral partition

by Spinnler, Christian

Hi all, I am currently trying out TF-M together with Zephyr and therefore ported it to the Nucleo-U575ZI-Q evaluation board. I started to struggle when trying to implement an example for a custom Secure Partition (SP) which should access peripherals. I recognized, that the `target_cfg.*` throughout different vendors follow different design principles. E.g. for Nordic controllers an example is given with their nordic-sdk on how to implement peripheral access for a SP (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/nrf/samples/tfm/…). For ST devices I tried to transfer this, however, where unsuccessful so far as for the ST microcontrollers the peripheral definitions are missing, and things are just different. Is there any example for ST controllers on how to make specific peripherals only accessible through SPE? Is this currently supported for ST devices? And another question, as the Embedded Open Source Summit arises, is TF-M represented somewhere on conferences? Kind Regards Christian Spinnler Siemens AG Technology Connectivity & Edge T CED SSI-DE Schuckertstrasse 2 91058 Erlangen, Deutschland mailto:christian.spinnler@siemens.com www.siemens.com<https://siemens.com> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Roland Busch, Vorsitzender; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin-Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322

2 years, 11 months

4
4
0 0

ARMCLANG protections bug

by Bohdan.Hunko＠infineon.com

Hi all, In GCC linker scripts ands of sections are aligned using following syntax: . = ALIGN(TFM_LINKER_XXX_ALIGNMENT); But in ARMClang TFM does not use similar approach, instead it creates Position tags sections like following: TFM_APP_CODE_START +0 ALIGN TFM_LINKER_APP_ROT_LINKER_CODE_ALIGNMENT EMPTY 0x0 { } TFM_APP_ROT_LINKER +0 ALIGN TFM_LINKER_APP_ROT_LINKER_CODE_ALIGNMENT { *tfm_app_rot_partition* (+RO-CODE, +RO-DATA) *libplatform_s* (TFM_*_APP-ROT_ATTR_FN) *.o (TFM_*_APP-ROT_ATTR_FN) } /* * This empty, zero long execution region is here to mark the end address * of APP RoT code. */ TFM_APP_CODE_END +0 ALIGN TFM_LINKER_APP_ROT_LINKER_CODE_ALIGNMENT EMPTY 0x0 { } I believe this is done because clang does not have syntaxes for aligning end of the section (please correct me if I am wrong). This approach results in bug in TFM_UNPRIV_CODE section protections, because TFM_UNPRIV_CODE Base and Limit are used directly and Limit is not aligned. For now this problem stayed undetected because present platforms does not validate region_limit when applying protections. I have created this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/21169> , which adds validation of region_limit and ran Ci on it and I can see that CI failed in tests for Clang builds So I guess this is the problem that have to be fixed. I see following possible solutions: 1. Align and of TFM_UNPRIV_CODE section (but I guess clang does not support that) 2. Add position tags for _START and END Solution 1 will simpler as it will not require changed in platform code, but I guess clang syntaxes is limiting us here. So my question would be whether there is a plan to fix this issue ? 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>

3 years

2
2
0 0

TFM Corstone1000 Cmake Error

by 박진국

Hi all. I am trying to port TFM using the corstone1000 platform. Previously, I was using the 1.7.0 version. TFM version was recently updated and I am trying to use the 1.8.0 version by downloading it from the site below. https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git As instructed by the site below ( https://tf-m-user-guide.trustedfirmware.org/platform/arm/corstone1000/readm… ) I executed the command below. cmake -B build/ -S . -DCMAKE_BUILD_TYPE=Debug -DTFM_TOOLCHAIN_FILE=<tf-m-root>/toolchain_GNUARM. cmake -DTFM_PLATFORM=arm/corstone1000 -DTEST_NS=OFF -DTEST_S=ON -DTEST_S_PS=OFF -DTEST_S_PLATFORM=OFF -DEXTRA_S_TEST_SUITE_PATH=platform/ext/target/arm/corstone1000/ci_regression_tests/ However, I got a cmake error as shown below. - Build type: Debug -- Host: Linux/x86_64 -- Target: Generic/arm -- Machine: template -- Host: Linux/x86_64 -- Target: Generic/arm -- Machine: template -- C_FLAGS : -mcpu=cortex-m0plus -Wall -Wextra CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:144 (target_sources): Cannot specify sources for target "platform_bl1" which is not built by this project. CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:168 (target_compile_definitions): Cannot specify compile definitions for target "platform_bl1" which is not built by this project. CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:175 (target_include_directories): Cannot specify include directories for target "platform_bl1_interface" which is not built by this project. I think this is caused by the target for platform_bl1 not being specified, but I don't know how to fix it. I executed cmake using the same configuration as set in corstone1000's config.cmake. Can anyone tell me why I am getting the above error? Any advice would be very helpful. thanks you.

3 years

4
4
0 0

TFM Corstone1000 Cmake Error

by 박진국

Hi all. I am trying to port TFM using the corstone1000 platform. Previously, I was using the 1.7.0 version.  TFM version was recently updated and I am trying to use the 1.8.0 version by downloading it from the site below. https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git As instructed by the site below  (https://tf-m-user-guide.trustedfirmware.org/platform/arm/corstone1000/readm…) I executed the command below. cmake -B build/ -S . -DCMAKE_BUILD_TYPE=Debug -DTFM_TOOLCHAIN_FILE=<tf-m-root>/toolchain_GNUARM. cmake -DTFM_PLATFORM=arm/corstone1000 -DTEST_NS=OFF -DTEST_S=ON -DTEST_S_PS=OFF -DTEST_S_PLATFORM=OFF -DEXTRA_S_TEST_SUITE_PATH=platform/ext/target/arm/corstone1000/ci_regression_tests/ However, I got a cmake error as shown below. - Build type: Debug -- Host: Linux/x86_64 -- Target: Generic/arm -- Machine: template -- Host: Linux/x86_64 -- Target: Generic/arm -- Machine: template -- C_FLAGS : -mcpu=cortex-m0plus -Wall -Wextra CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:144 (target_sources):   Cannot specify sources for target "platform_bl1" which is not built by this   project. CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:168 (target_compile_definitions):   Cannot specify compile definitions for target "platform_bl1" which is not   built by this project. CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:175 (target_include_directories):   Cannot specify include directories for target "platform_bl1_interface"   which is not built by this project. I think this is caused by the target for platform_bl1 not being specified, but I don't know how to fix it. I executed cmake using the same configuration as set in corstone1000's config.cmake. Can anyone tell me why I am getting the above error? Any advice would be very helpful. thanks you.

3 years

1
0
0 0

TFM Corstone1000 Cmake Error

by 박진국

Hi all. I am trying to port TFM using the corstone1000 platform. Previously, I was using the 1.7.0 version.  TFM version was recently updated and I am trying to use the 1.8.0 version by downloading it from the site below. https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git As instructed by the site below  (https://tf-m-user-guide.trustedfirmware.org/platform/arm/corstone1000/readm…) I executed the command below. cmake -B build/ -S . -DCMAKE_BUILD_TYPE=Debug -DTFM_TOOLCHAIN_FILE=<tf-m-root>/toolchain_GNUARM. cmake -DTFM_PLATFORM=arm/corstone1000 -DTEST_NS=OFF -DTEST_S=ON -DTEST_S_PS=OFF -DTEST_S_PLATFORM=OFF -DEXTRA_S_TEST_SUITE_PATH=platform/ext/target/arm/corstone1000/ci_regression_tests/ However, I got a cmake error as shown below. - Build type: Debug -- Host: Linux/x86_64 -- Target: Generic/arm -- Machine: template -- Host: Linux/x86_64 -- Target: Generic/arm -- Machine: template -- C_FLAGS : -mcpu=cortex-m0plus -Wall -Wextra CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:144 (target_sources):   Cannot specify sources for target "platform_bl1" which is not built by this   project. CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:168 (target_compile_definitions):   Cannot specify compile definitions for target "platform_bl1" which is not   built by this project. CMake Error at platform/ext/target/arm/corstone1000/CMakeLists.txt:175 (target_include_directories):   Cannot specify include directories for target "platform_bl1_interface"   which is not built by this project. I think this is caused by the target for platform_bl1 not being specified, but I don't know how to fix it. I executed cmake using the same configuration as set in corstone1000's config.cmake. Can anyone tell me why I am getting the above error? Any advice would be very helpful. thanks you.

3 years

1
0
0 0

Using bitwise or (|) / and (&) in Clang scatter file

by Bohdan.Hunko＠infineon.com

Hi For our platform we use some ,across which should set/clear bit 28 of an address (see code below). We do this for convenience reasons. #define IFX_S_ADDRESS_ALIAS(x) ((x) | 0x10000000) #define IFX_NS_ADDRESS_ALIAS(x) ((x) & ~0x10000000) Those macros are used in declaration of S_CODE_START macro. When expended in linker script (tfm_isolation_l3.o), the declaration of LR_CODE section looks as follows: LR_CODE (0x24000000 | 0x10000000) (0x4B000) { This code results in following error: tfm_isolation_l3.o", line 46 (column 21): Error: L6292E: Ignoring unknown attribute '|' specified for region LR_CODE. I tried experimenting with this and found out that when | is changed to or (see following code) then linker works fine: LR_CODE (0x24000000 or 0x10000000) (0x4B000) { Same problem is present when using bitwise and (&). But when using bitwise NOT (~0x...) everything works fine. Having to define our macros in different way brings some problems for our platform, so maybe someone knows how to solve this problem? Maybe there are compilation flags or something like that? Ideally we want | and & to work fine in linker script. Thanks! 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>

3 years

2
2
0 0

Trying to debug TF-M across NS/S boundary

by Lena Boeckmann

Hi! I found the e-mail below from 2020 and this is exactly where I'm at right now: I have a Zephyr application with TF-M flashed on an nrf9160dk and managed to open a debugging session following the explanation here: https://tf-m-user-guide.trustedfirmware.org/platform/nxp/lpcxpresso55s69/RE… (might be good to mention in the documentation that this also works on other platforms or have a general "Debug with GDB section"). So far I can either debug the secure image or or the non-secure image, but I would actually like to see the communication between the two. Is it even possible to debug across the boundary? I'm not very experienced in using GDB (except for the basics). Is there some kind of TF-M specific tutorial or explanation by now? Or is there anyone who can give me a hint on how to do this? Kind regards, Lena Kevin Townsend wrote: > Hi Anton, > One particular difficulty I've encountered working with TF-M for the Zephyr > certification demo app, and with the LPC55S69 port to upstream TF-M is the > debugging experience with GDB and the dual execution environments. GDB can > be quite powerful if you are familiar with it, but there is a definite > learning curve, and the S and NS separation and the dual binary images > (three with BL2) adds an additional degree of complexity. > I think having a dedicated debugging tutorial around GDB would be very > useful to people adopting TF-M and perhaps new to GDB, just to show how > some basic debugging might happen, how to debug across the NS/S boundary, > etc. > For example, the '--tui' option for GDB may not be very well known, and it > may be useful to highlight (see screenshots at the bottom of this issue: > https://github.com/microbuilder/trusted-firmware-m/issues/1) > Practical, step-by-step debugging documentation just seems like a good > investment to help flatten this inevitable learning curve developing > real-world solutions with TF-M? > Best regards, > Kevin > On Thu, 27 Feb 2020 at 13:13, Anton Komlev via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > > A kind reminder. > > Your feedback is valuable all the time with no deadline defined. > > *From:* TF-M tf-m-bounces(a)lists.trustedfirmware.org * On Behalf Of *Anton > > Komlev via TF-M > > *Sent:* 07 February 2020 13:13 > > *To:* tf-m(a)lists.trustedfirmware.org > > *Cc:* nd nd(a)arm.com > > *Subject:* [TF-M] Call for a feedback on TF-M adaptation experience > > Dear All, > > As I mentioned on yesterday’s call, there is a concern on user experience > > related to TF-M use. > > To In order to understand and potentially improve it I am looking for a > > voice of partners who adopted TF-M project. > > Please share your experience and thoughts on parts which are good or might > > be done better to simplify TF-M integration with your project. > > You feedback will be very appreciated in any form – as a response to this > > mail or as a direct mail to me (anton.komlev(a)arm.com) if it’s more > > comfortable for you. > > Thank you in advance, > > Anton > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > >

3 years

2
1
0 0

Branch release/1.7.x to be deleted

by Anton Komlev

Hi, I plan to delete the branch release/1.7.x at the end of this week (after May 26) following TF-M release process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Please let me know if someone is dependent on it and needs more time to detach from it. Thanks, Anton

3 years

1
0
0 0

psa_call performance

by Quach, Brian

Hi, Using isolation level 1 and IPC secure partition, I noticed psa_call() overhead for TFM v1.7 is significantly worse for than v1.1. Is this expected? Assuming 1 invec and 0 outvec for the PSA call.... TF-M version Psa_call() round trip cycles v1.1 4038 v1.7 6051 Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

3 years

6
16
0 0

Querying Anyone Using Shared Memory to Share Lifecycle, Bootseed, Hardwareversion Info

by Sherry Zhang

Hi, Currently in the Attestation partition, when encoding the security lifecycle, boot seed, and hardware version claims, these info are searched in the shared memory firstly before calling the platform hal APIs. See the code here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>. Sharing this information via shared memory is a legacy mechanism and MCUboot does not writes that information when booting. And calling the platform hal APIs way is recommended. I created this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/21021> removes looking for the security lifecycle, boot seed, and hardware version from shared memory. Before opening this patch for review, I would like to query whether this mechanism is being used by any platform. Is there any platform(which suppose runs a bootloader which is not MCUboot) using this sharing memory mechanism to provide the security lifecycle, boot seed, and hardware version information now? Thanks, Regards, Sherry Zhang

3 years

1
0
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>

3 years

4
5
0 0

How to solve the link error while enable both mbedTLS and TF-M crypto interfaces in NSPE

by Edward Yang

Hi experts, Recently we're developing an example demo based on TF-M, the application scenario is simplified as below. MbedTLS module in NSPE is used to guarantee the secure communication with AWS cloud, while TF-M in SPE provides data encryption/decryption and sensitive data storage services. So both TF-M interfaces and mbedtls module are enabled on NSPE, there will be two implementations of PSA Crypto and this will result in a link error. The red box displays files with conflicts between mbedtls and TF-M, which prevent the project from compiling. Can all TF-M code be converted into a lib to avoid linking issues? Or is there any other way to solve this problem? Best Regards, Poppy Wu http://www.mxic.com.cn

3 years

5
6
0 0

Re: [tfm_test_repo]why should the sha_1 not be supported at secure test suite

by zhilei.wang＠bekencorp.com

Hi, Antonio, Get it. Thank you very much Best Regards zhilei.wang | bekencorp From: Antonio De Angelis via TF-M Date: 2023-05-11 20:35 To: tf-m CC: nd Subject: [TF-M] Re: [tfm_test_repo]why should the sha_1 not be supported at secure test suite Hi Zhilei, The configuration of the TF-M Crypto service that it’s tested by default is just an example, and the SHA-1 algorithm is allowed from the PSA spec point of view; in our case we have decided to not enable SHA-1 support due to the fact that it’s widely accepted to have known collision attacks [1], NIST deprecating it in 2011 [2], and having exposed weaknesses since long, 2005 [3], i.e. to encourage by default having a look into more robust alternatives. Anyway, TF-M’s test 1010 just aims at testing the interface for the correct error response, nothing more. If your deployment still supports PSA_ALG_SHA_1, I’d recommend to just ignore the output of TEST_1010. On our side, we could gate the test not to run when PSA_WANT_ALG_SHA_1 is defined. Thanks, Antonio [1] SHAttered [2] NIST Retires SHA-1 Cryptographic Algorithm | NIST [3] 010.pdf (iacr.org) From: zhilei.wang(a)bekencorp.com <zhilei.wang(a)bekencorp.com> Sent: Thursday, May 11, 2023 13:44 To: tf-m <tf-m(a)lists.trustedfirmware.org> Cc: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; Summer Qin <Summer.Qin(a)arm.com>; poppywu <poppywu(a)mxic.com.cn> Subject: [tfm_test_repo]why should the sha_1 not be supported at secure test suite Hi, Why should the sha_1 not be supported at secure test suite? Our soc has a cypto accelerator, that supports sha_1/224 and so on. The following is the detail. File: \tfm\lib\ext\tfm_test_repo-src\test\secure_fw\suites\crypto\secure\crypto_sec_interface_testsuite.c Function: static void tfm_crypto_test_1010(struct test_result_t *ret) { psa_unsupported_hash_test(PSA_ALG_SHA_1, ret); } Thanks and best regards, zhilei.wang bekencorp

3 years

1
0
0 0

[tfm_test_repo]why should the sha_1 not be supported at secure test suite

by zhilei.wang＠bekencorp.com

Hi, Why should the sha_1 not be supported at secure test suite? Our soc has a cypto accelerator, that supports sha_1/224 and so on. The following is the detail. File: \tfm\lib\ext\tfm_test_repo-src\test\secure_fw\suites\crypto\secure\crypto_sec_interface_testsuite.c Function: static void tfm_crypto_test_1010(struct test_result_t *ret) { psa_unsupported_hash_test(PSA_ALG_SHA_1, ret); } Thanks and best regards, zhilei.wang bekencorp

3 years, 1 month

2
1
0 0

TF-M Confidential AI presentation next tech forum?

by Kevin Townsend

Hi, I'd like to propose presenting some of the work we've done around "Confidential AI" with TF-M and Zephyr during the next TF Tech Forum call. I think I'll probably need 30 minutes or so, and can take some questions after time and agenda permitting. If you're not familiar with the project, it's an attempt at trying to determine how open standards and open source software (Zephyr, TF-M, MCUBoot, etc.) can be used together in a practical, end-to-end security use case ... in this case, running inference on sensor data in the secure partition, and transmitting sensitive data from S to NS to the cloud. Relevant repos are here, but of course I'll try to give a meaningful overview of all of this during the call since the project has several related components: - https://github.com/Linaro/zephyr_confidential_ai - https://github.com/Linaro/lite_bootstrap_server Thanks and best regards, Kevin Townsend Tech Lead - LITE, Vertical Technologies Linaro.org │ Open source software for ARM SoCs

3 years, 1 month

1
0
0 0

SP FPU config

by Quach, Brian

Hi, Is it correct that CONFIG_TFM_FP_ARCH_ASM is 'empty string' when using FP_ARCH_FPV5_SP_D16? I'm wondering if it should be set to "FPv5-SP" ############################## FP Arch ######################################### config FP_ARCH_FPV5_D16 def_bool n help FPv5-D16 config FP_ARCH_FPV5_SP_D16 def_bool n help FPv5-SP-D16 config CONFIG_TFM_FP_ARCH string default "fpv5-d16" if FP_ARCH_FPV5_D16 default "fpv5-sp-d16" if FP_ARCH_FPV5_SP_D16 default "" config CONFIG_TFM_FP_ARCH_ASM string default "FPv5_D16" if FP_ARCH_FPV5_D16 default "" Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

3 years, 1 month

2
1
0 0

Release v1.8.0 changes are merged.

by Anton Komlev

Hello, The changes made for the TF-M v1.8.0 are merged back to the master branch. To allow that, Corstone-1000 platform was temporarily excluded from OpenCI tests because the platform changes in the release branch conflicted with changes in the master, made in parallel. The platform will be back under test immediately after the conflict resolution. Corstone-1000 platform builds and runs correctly under v1.8.0 tag. Thanks, Anton

3 years, 1 month

1
0
0 0

TF-M release v1.8.0 announcement

by Anton Komlev

Hello, I am pleased to announce the release of TF-M v1.8.0<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.8…>. New major features are: * TF-M eRPC Test framework 1 is integrated. * TF-M builtin key loader integration is reworked. * Improved crypto library abstraction from TF-M Crypto service. * Kconfig system is enhanced and finalized. * Switch to upstream QCBOR 2. * Enable PSA Authenticated Debug Access Control (ADAC) 3 support on Musca-B1 platform. * Support Floating-Point (FP) with Arm Compiler. * FF-M API uses signals to drive the partition scheduling instead of controlling partition context directly. * MCUboot upgrade to v1.10.0. * Mbed TLS upgrade to v3.4.0. * Refine documentation restructure. * It is optional to update copyright year in changes. Requirements of copyright note update is updated in Contributing Process. Please check the release notes<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/relea…> for more information. The release branch changes will be ported to the main branch shortly. Many thanks to everyone for contributing, reviewing and supporting this milestone. Anton

3 years, 1 month

1
0
0 0

SVC handlers refining

by Ken Liu

Hello, For isolation levels > 1, partitions need to SVC for PSA APIs. To improve the efficiency of this call type, the SVC handler needs to be simplified. Currently, there are several obvious places to be improved: - Handlers in C have multiple-level function calling; - There are a couple of checks in the handler routine that can be refined. And, to take advantage of instruction TBB, the switch/case number needs to be linear - but it is not always stable hence needs to investigate if a handmade function table would be more stable. The leading patches are here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20644 Feel free to comment or reply in this thread. Thanks. /Ken

3 years, 1 month

1
0
0 0

Adjustments for SVC number assignments that impact platforms with platform-specific SVC

by Kevin Peng

Hi, We're making some adjustments for the SVC number assignments. I'd like to collect some feedbacks, especially from downstream platforms that have your own SVC handler because corresponding changes of your SVC numbers are required when these changes were accepted. Originally, The SVC numbers are categorized by their values, for example, numbers less than 0x40 are PSA API requests and numbers larger than 0x80 are for handler mode. This is not convenient for adding new SVC because it's not intuitive to find a proper value range. More importantly, it's easy to create clashes between TF-M and platform SVC by mistake as they are defined in different files. So, we propose to divide the SVC number bits into different fields for distinguishing different types of SVC. Please see here<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20644/1/secu…> for the detailed descriptions. With these changes, it's much easier to put the SVC numbers in the right range and avoid duplications after setting the bit fields to right values. Thanks, Kevin

3 years, 1 month

1
0
0 0

ITS cmake

by Quach, Brian

Is the highlighted line below correct? Or should the angle bracket be at the end like this: $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/../protected_storage> target_include_directories(tfm_psa_rot_partition_its PRIVATE $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> ${CMAKE_BINARY_DIR}/generated/secure_fw/partitions/internal_trusted_storage PUBLIC # Required for ps_object_defs.h $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>/../protected_storage ) Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

3 years, 1 month

2
1
0 0

PSA Crypto platform specific extensions

by Roman.Mazurak＠infineon.com

Hello everyone, I need to extend PSA Crypto API by adding a platform specific encryption algorithm/key attribute. For example a vendor specific algorithm named ABC must be added. So, I need that following macro must be included when psa/crypto.h is included. #define PSA_ALG_ABC ((psa_algorithm_t) 0x08000123) TF-M provides PSA Crypto interface through includes located in interface/include/psa/crypto*.h. It means that we need to extend TF-M by allowing platform to provide some platform specific crypto header that will be installed in interface folder and included by psa/crypto.h. 1. Is there any activity related to this problem? 2. I'm considering to create a new crypto_config.h that must be generated during build process and which can optionally provide a macro TFM_PLATFORM_CRYPTO_EXTRA. These macro will be used in psa/crypto.h to conditionally include crypto_platform.h - header provided by platform. Thanks, Roman.

3 years, 1 month

2
1
0 0

Start of TF-M v1.8.0 release

by Anton Komlev

Hello, The branch release/1.8.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=release/…> has been created indicating the start of the release process and features freeze. RC1 tag will follow after a successful run of the basic tests. Let me remind that the code is not frozen, and development can be continued on the main branch as described in TF-M Release Process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Thanks, Anton

3 years, 1 month

2
3
0 0

Request for Review: Add platform specific default UART configurations

by Andersson, Joakim

Hi. We at Nordic are running the TF-M regression and PSA architecture tests on our boards, and we get occasional issues with test output because HW flow control is by default disabled in CMSIS. To enable HW flow control in the TF-M we must change the call to the CMSIS UART driver. I've created a change to allows the platform to set any non-default CMSIS configuration, such as HW flow control: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20374 I'd like to ask all platform maintainers to review this change. This change must add another define to all supported platforms, the change itself should not cause any difference in actual behavior. This can be used for other non-default UART configuration in other platforms as well. -Joakim Andersson

3 years, 1 month

1
0
0 0

Support of MCUBOOT_IMAGE_NUMBER > 2

by Bohdan.Hunko＠infineon.com

Hi all, PSA FWU API update to version 1.0 made it easy to support updates of more than 2 images. To do so platform may define its own FWU_DEVICE_CONFIG_FILE which will contain definitions for all the components. So it looks like in current implementation FWU service should easily support FWU_COMPONENT_NUMBER > 2 (for example FWU_COMPONENT_NUMBER = 4) The only place that I see that doesn't support this is secure_fw/partitions/firmware_update/bootloader/mcuboot/tfm_mcuboot_fwu.c file which have following code: #if (MCUBOOT_IMAGE_NUMBER == 1) #define MAX_IMAGE_INFO_LENGTH (sizeof(struct image_version) + \ SHARED_DATA_ENTRY_HEADER_SIZE) #else #define MAX_IMAGE_INFO_LENGTH 2 * (sizeof(struct image_version) + \ SHARED_DATA_ENTRY_HEADER_SIZE) #endif So if MCUBOOT_IMAGE_NUMBER is 4 then MAX_IMAGE_INFO_LENGTH will only account for 2 images. To fix this I propose to change the code to: #define MAX_IMAGE_INFO_LENGTH MCUBOOT_IMAGE_NUMBER * (sizeof(struct image_version) + \ SHARED_DATA_ENTRY_HEADER_SIZE) This change will allow platform to support update of more than 2 components (assuming that platforms implementation of bootloader supports that) So I have few questions: 1. Will such change be accepted upstream? Do you see any problems with this change?\ 2. Are there already platforms that support update of more than 2 components? 3. Are there any known problems with supporting update of more than 2 components? 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>

3 years, 1 month

2
2
0 0

[RFC] Updated mailbox agent API documents

by Ken Liu

Hi, The mailbox agent API was proposed before and this time more implementation details are introduced in the document: Docs: Implementation details for Mailbox Agent API (Ifec409eb) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20421> Feel free to comment, and feel free to create implementations for it - remember response to this thread before you do. Thanks. /Ken

3 years, 2 months

1
0
0 0

s_veneers linking problem when building uboot with flags -pie

by xulu＠allwinnertech.com

Hi experts, Recently we are building uboot with s_veneers.o, and found that we can not jump to tfm. The reason is that the jump addr is wrong when compileing with -pie. The symbol "tfm_vendor_aes_encrypt_with_hardware_ssk" in s_veneers.o. $ nm ./drivers/tfm/lib/s_veneers.o | grep tfm_vendor_aes_encrypt_with_hardware_ssk 04008029 A tfm_vendor_aes_encrypt_with_hardware_ssk Building uboot without cflags -pie, and the last line shows the wrong jump addr 0xf7fc7e61 0c0401f0 <__tfm_vendor_efuse_write_veneer>: c0401f0: b401 push {r0} c0401f2: 4802 ldr r0, [pc, #8] ; (c0401fc <__tfm_vendor_efuse_write_veneer+0xc>) c0401f4: 46fc mov ip, pc c0401f6: 4484 add ip, r0 c0401f8: bc01 pop {r0} c0401fa: 4760 bx ip c0401fc: f7fc7e61 .word 0xf7fc7e61 Building uboot without cflags -pie，and the last line shows the right jump addr 0x04008029. 0c040200 <__tfm_vendor_aes_encrypt_with_hardware_ssk_veneer>: c040200: b401 push {r0} c040202: 4802 ldr r0, [pc, #8] ; (c04020c <__tfm_vendor_aes_encrypt_with_hardware_ssk_veneer+0xc>) c040204: 4684 mov ip, r0 c040206: bc01 pop {r0} c040208: 4760 bx ip c04020a: bf00 nop c04020c: 04008029 .word 0x04008029 The linker flag -pie is default enabled in uboot(for relocation feature), and we need this feature. Could you please give us some pointers, suggestions or objections about this problem, Thanks!

3 years, 2 months

2
1
0 0

Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation test

by Edward Yang

Hi Antonio, Thank you for taking the time to help confirm the function, and we've found out that this error just resulted from the incorrect initialization of 'operation' before calling PSA APIs, after fixing this bug, we also got the correct OKM. Thanks again for your support. Best Regards, Poppy Wu 吴偏偏 http://www.mxic.com.cn Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> 2023/03/23 21:58 Please respond to Antonio De Angelis <Antonio.DeAngelis(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject [TF-M] Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation test Hi, I have tried the example below on mbed TLS running on an x86 Linux based host machine, and on the AN521 platform, and in both cases I can get consistent results, i.e. the value of the okm buffer at the end is: 0x3c, 0xb2, 0x5f, 0x25, 0xfa, 0xac, 0xd5, 0x7a, 0x90, 0x43, 0x4f, 0x64, 0xd0, 0x36, 0x2f, 0x2a, 0x2d, 0x2d, 0x0a, 0x90, 0xcf, 0x1a, 0x5a, 0x4c, 0x5d, 0xb0, 0x2d, 0x56, 0xec, 0xc4, 0xc5, 0xbf, 0x34, 0x00, 0x72, 0x08, 0xd5, 0xb8, 0x87, 0x18, 0x58, 0x65 Which I believe matches the expected output below. Given that your issue seems to be specific to the stm32l562e_dk platform, which uses its own crypto accelerator I believe rather than pure software implementation, I would suggest to have a look at the intermediate steps and compare your results against the AN521 platform results. You might want to raise this behaviour to the platform maintainer, as at this stage this seems to me to be a platform specific issue. I can only confirm that you are not misusing the PSA Crypto APIs here. Let me know if I can be of any more help. Thanks, Antonio From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, March 23, 2023 12:51 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation test I am going to have a look into this. Thanks for the instructions on how to reproduce. Might get a while to reply, please bear with me. Thanks, Antonio From: Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, March 23, 2023 01:36 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Please help check the failure of PSA_ALG_HKDF_EXPAND operation test Hi experts, Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on stm32l562e_dk platform. But the HKDF-EXPAND output didn't match the expected OKM. The test vector is as below: ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256), "info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"), "L" : 42, "PRK" : "077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5" "OKM" : "3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865" The corresponding code is as follow： int8_t okm[42]={0}; uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9}; uint8_t ikm[]= { 0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf, 0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63, 0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31, 0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5 }; status = psa_key_derivation_setup(&operation, PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_SECRET, ikm, sizeof(ikm)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_INFO, info, sizeof(info)); status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm) ); The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b 2e 19 18 77 ae, which didn't match the OKM of above test vector. Have we misused the HKDF-EXPAND operation? Best Regards, Poppy Wu 吴偏偏 http://www.mxic.com.cn -- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org

3 years, 2 months

1
0
0 0

How does TF-M deal with the faults originated from NSPE

by Sandeep Tripathy

Hi tf-m experts, I have a fundamental query on v8m trustZone and containability of secure fault and other escalated HardFaults to SPE. With BFHFNMINA set to '0' IIUC that a malicious actor in NSPE can willingly cause fault in SPE ? Is there a way to contain the fault in NS world? Thanks Sandeep

3 years, 2 months

4
5
1 0

Please help check the failure of PSA_ALG_HKDF_EXPAND operation test

by Edward Yang

Hi experts, Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on stm32l562e_dk platform. But the HKDF-EXPAND output didn't match the expected OKM. The test vector is as below: ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256), "info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"), "L" : 42, "PRK" : "077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5" "OKM" : "3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865" The corresponding code is as follow： int8_t okm[42]={0}; uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9}; uint8_t ikm[]= { 0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf, 0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63, 0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31, 0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5 }; status = psa_key_derivation_setup(&operation, PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_SECRET, ikm, sizeof(ikm)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_INFO, info, sizeof(info)); status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm) ); The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b 2e 19 18 77 ae, which didn't match the OKM of above test vector. Have we misused the HKDF-EXPAND operation? Best Regards, Poppy Wu 吴偏偏 http://www.mxic.com.cn

3 years, 2 months

2
2
0 0

Please help check the failure of PSA_ALG_HKDF_EXPAND operation test

by Wenhua You

Hi experts, Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on stm32l562e_dk platform. But the HKDF-EXPAND output didn't match the expected OKM. The test vector is as below: ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256), "info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"), "L" : 42, "PRK" : "077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5" "OKM" : "3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865" The corresponding code is as follow： int8_t okm[42]={0}; uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9}; uint8_t ikm[]= { 0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf, 0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63, 0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31, 0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5 }; status = psa_key_derivation_setup(&operation, PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_SECRET, ikm, sizeof(ikm)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_INFO, info, sizeof(info)); status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm) ); The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b 2e 19 18 77 ae, which didn't match the OKM of above test vector. If we've misused the HKDF-EXPAND operation? Best Regards, 尤文华 Wenhua You 旺宏微电子（苏州）有限公司 Macronix Microelectronics(Suzhou) Co., Ltd. 地址：中国苏州工业园区苏虹西路55号 No.55，Su Hong Xi Road，Suzhou Industrail Park，Suzhou 215021 P.R.China TEL: 86-512-62580888 EXT: 3115 FAX: 86-512-62585399 ZIP: 215021 E-mail: wenhuayou(a)mxic.com.cn Http: //www.mxic.com.cn

3 years, 2 months

1
0
0 0

Sealing key - RSS

by Peter Sawicki

As far as ARM CCA is concerned, currently RSS supports only measured boot and delegated attestation (fetching DAK and CCA platform attestation token) interfaces. The Arm CCA Security Model 1.0 mentions that if a Realm wants to implement a persistent secure storage, the platform should deliver binding keys for local protection of persistent Realm assets. Is there any ARM CCA specification that explains how this key should be derived? Are there any plans to implement such functionality in RSS? Kind regards, Peter

3 years, 2 months

3
4
0 0

TF-M scheduling

by Chris.Brand＠infineon.com

Hi, I've read https://tf-m-user-guide.trustedfirmware.org/integration_guide/non-secure_cl… and https://tf-m-user-guide.trustedfirmware.org/design_docs/software/tfm_cooper… but I'm not sure that I understand the whole system. For example, in this scenario: 1. NSPE is running a low-priority thread which has called into the PSA API. S partition is running to do the work. 2. NS interrupt occurs. 3. NS RTOS determines that a higher-priority thread should now run. At step 2, the S context gets stored on the S stack. I guess at step 3 the NS RTOS ISR would manipulate the stack so that it "returns" to the higher-priority NS thread rather than to the secure partition? And then sometime later when it schedules in the low-priority thread, it will return to the interrupted S partition. So the higher-priority thread can also make a PSA API call (provided the NS RTOS is notifying TF-M of the scheduling decisions it makes)? 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> 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.

3 years, 2 months

1
0
0 0

Scheduler problem

by Bohdan.Hunko＠infineon.com

Hi everyone, Why investigation some interrupts related stuff I have noticed a problem/bug in the scheduler. PendSV_Handler has following code: " movs r0, #"M2S(EXC_RETURN_SECURE_STACK)" \n" " mov r1, lr \n" " tst r0, r1 \n" /* NS interrupted */ " beq v8b_pendsv_exit \n" /* No schedule */ Which means that if NSPE was interrupted then no scheduling will be done. This created a problem in following scenario: 1. NSPE is executing 2. Secure interrupts arrives. 3. NSPE is interrupted, secure interrupt is handled. 4. Secure interrupts triggers scheduling of some partition. 5. Secure interrupt returns 6. Scheduling is triggered 7. PendSV returns (because /* NS interrupted */ /* No schedule */ ) and does not perform scheduling even thought pending partition is present. This means that pending partition will only be scheduled when next PSA call will be done be NSPE. Even if there would be subsequent Secure interrupts that preempt NSPE, partition will not be scheduled because PendSV will always return without scheduling because NSPE was interrupted. I was not able to find any information about this in TFM docs so I assume this is a bug. Please let me know if I am wrong. And if this is real problem then is there a plan to fix this? 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>

3 years, 2 months

2
1
0 0

Support mbedTLS 3.3.0

by S Krishnan, Archanaa

Hi, TF-M v1.7 utilizes mbedTLS v3.2.1. Are there plans to update to mbedTLS v3.3.0? Regards, Archanaa

3 years, 3 months

2
1
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>

3 years, 3 months

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.

3 years, 3 months

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

3 years, 3 months

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>

3 years, 3 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

3 years, 3 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

3 years, 3 months

1
0
0 0

Multi-Core Memory Access Check document is outdated

by Bohdan.Hunko＠infineon.com

Hi, https://tf-m-user-guide.trustedfirmware.org/technical_references/design_doc… seems to be outdated. It has references tfm_core_has_read_access_to_region(), tfm_core_has_write_access_to_region() and other outdated info. Could the document be updated by the owner ? 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>

3 years, 3 months

2
2
0 0

TF-M copyright year update

by Anton Komlev

Hi, This is a continue of discussion started on today's forum on the value of copyright year update on every change. I proposed to let such update being optional and do not track it in review. There was no objection during forum but an alternative proposal to adopt the Linux Foundation guidance<https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-…>, where all authors and contributors are listed in a separate while source and documentation are free from it. For example MbedTLS doing that way, although it has side effects: * Need to modify all files in 6 repositories. * Gather permission from all copyright holders. Looking for more opinions on the topic. Thanks, Anton

3 years, 4 months

4
5
0 0

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

by Edward Yang

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? The detailed build log is as below: (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trusted-firmware-m/cmake_build# cmake .. -DTFM_PLATFORM=stm/stm32l562e_dk -DTEST_PSA_API=CRYPTO Start to generate partition files: Generating Protected Storage Service in /home/a/workspace1/TF-M/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/protected_storage Generating TF-M Internal Trusted Storage Service in /home/a/workspace1/TF-M/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/internal_trusted_storage Generating TFM Crypto Service in /home/a/workspace1/TF-M/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/crypto Generating TFM Platform Service in /home/a/workspace1/TF-M/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/platform Generating TFM Initial Attestation Service in /home/a/workspace1/TF-M/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/initial_attestation Per-partition files done: -- ---------- Display crypto configuration - start -------------- -- CRYPTO_RNG_MODULE_DISABLED is set to FALSE -- CRYPTO_KEY_MODULE_DISABLED is set to FALSE -- CRYPTO_AEAD_MODULE_DISABLED is set to FALSE -- CRYPTO_MAC_MODULE_DISABLED is set to FALSE -- CRYPTO_CIPHER_MODULE_DISABLED is set to FALSE -- CRYPTO_HASH_MODULE_DISABLED is set to FALSE -- CRYPTO_KEY_DERIVATION_MODULE_DISABLED is set to FALSE -- CRYPTO_ASYM_SIGN_MODULE_DISABLED is set to FALSE -- CRYPTO_ASYM_ENCRYPT_MODULE_DISABLED is set to FALSE -- CRYPTO_ENGINE_BUF_SIZE is set to 0x5000 -- CRYPTO_CONC_OPER_NUM is set to 8 -- CRYPTO_IOVEC_BUFFER_SIZE is set to 5120 -- ---------- Display crypto configuration - stop --------------- -- ----------- Display storage configuration - start ------------ -- PS_CREATE_FLASH_LAYOUT is set to ON -- PS_ENCRYPTION is set to ON -- PS_RAM_FS is set to OFF -- PS_ROLLBACK_PROTECTION is set to ON -- PS_VALIDATE_METADATA_FROM_FLASH is set to ON -- PS_MAX_ASSET_SIZE is set to 2048 -- PS_NUM_ASSETS is set to 10 -- PS_CRYPTO_AEAD_ALG is set to PSA_ALG_GCM -- ITS_CREATE_FLASH_LAYOUT is set to ON -- ITS_RAM_FS is set to OFF -- ITS_VALIDATE_METADATA_FROM_FLASH is set to ON -- ITS_MAX_ASSET_SIZE is set to 1229 -- ITS_NUM_ASSETS is set to 10 -- ITS_BUF_SIZE is not set (defaults to ITS_MAX_ASSET_SIZE) -- ----------- Display storage configuration - stop ------------- -- [PSA] : ----------Process input arguments- start------------- -- [PSA] : TARGET is set to tgt_dev_apis_tfm_stm32l562e_dk -- [PSA] : SUITE is set to CRYPTO -- [PSA] : TOOLCHAIN is set to GNUARM -- [PSA] : CPU_ARCH is set to armv8m_ml -- [PSA] : VERBOSE is set to 3 -- [PSA] : WATCHDOG_AVAILABLE is set to 1 -- [PSA] : Default spec version -- [PSA] : TESTS_COVERAGE set to ALL, therefore all tests are included. -- [PSA] : ----------Process input arguments- complete------------- -- [PSA] : Creating testlist.txt 'available at /home/a/workspace1/TF-M/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/crypto_testlist.txt' Non-secure test entry symbol list: /home/a/workspace1/TF-M/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/test_entry_list.inc, /home/a/workspace1/TF-M/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/test_entry_fn_declare_list.inc [PSA] : _C_TOOLCHAIN_PATH /home/a/Tools/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc. -- [PSA] : C compiler used '/home/a/Tools/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc' -- [PSA] : ASM compiler used '/home/a/Tools/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc' -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trusted-firmware-m/cmake_build (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trusted-firmware-m/cmake_build# make install Scanning dependencies of target tfm_fih_implementation [ 0%] Building C object lib/fih/CMakeFiles/tfm_fih_implementation.dir/src/fih.o [ 0%] Linking C static library libtfm_fih_implementation.a [ 0%] Built target tfm_fih_implementation Scanning dependencies of target tfm_generated_files [ 0%] Built target tfm_generated_files Scanning dependencies of target tfm_s_scatter [ 0%] Building C object platform/target/CMakeFiles/tfm_s_scatter.dir/__/__/__/common/gcc/tfm_common_s.ld [ 0%] Built target tfm_s_scatter Scanning dependencies of target tfm_qcbor_s [ 0%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/ieee754.o [ 0%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/qcbor_encode.o [ 0%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/qcbor_decode.o [ 1%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/UsefulBuf.o [ 1%] Linking C static library libtfm_qcbor_s.a [ 1%] Built target tfm_qcbor_s Scanning dependencies of target tfm_t_cose_s [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_sign1_sign.o [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_sign1_verify.o [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_util.o [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_parameters.o [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/crypto_adapters/t_cose_psa_crypto.o [ 2%] Linking C static library libtfm_t_cose_s.a [ 2%] Built target tfm_t_cose_s Scanning dependencies of target crypto_service_crypto_hw [ 2%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/hal/accelerator/rsa_alt.o [ 2%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/hal/accelerator/ecdsa_alt.o [ 2%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/hal/accelerator/aes_alt.o [ 2%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/hal/accelerator/gcm_alt.o [ 3%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/hal/accelerator/ccm_alt.o [ 3%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/hal/accelerator/ecp_alt.o [ 3%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/hal/accelerator/ecp_curves_alt.o [ 3%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/hal/accelerator/sha1_alt.o [ 3%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/hal/accelerator/sha256_alt.o [ 3%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/hal/accelerator/stm.o [ 3%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/hal/accelerator/huk.o [ 3%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash.o [ 4%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash_ex.o [ 4%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pka.o [ 4%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp.o [ 4%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp_ex.o [ 4%] Building C object platform/ext/accelerator/CMakeFiles/crypto_service_crypto_hw.dir/__/target/stm/common/hal/Native_Driver/low_level_rng.o [ 4%] Linking C static library libcrypto_service_crypto_hw.a [ 4%] Built target crypto_service_crypto_hw Scanning dependencies of target platform_s [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/secure/system_stm32l5xx.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/hal/Native_Driver/tick.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/hal/Native_Driver/mpu_armv8m_drv.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/secure/spm_hal.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/secure/tfm_hal_isolation.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/secure/tfm_hal_platform.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/secure/target_cfg.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/secure/low_level_device.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/hal/CMSIS_Driver/low_level_flash.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/hal/CMSIS_Driver/low_level_com.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cortex.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_flash.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_flash_ex.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_dma.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pwr.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pwr_ex.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_gpio.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_uart.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_uart_ex.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_rcc.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_rcc_ex.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_gtzc.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_isolation_mpu_v8m.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_nvic.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/secure/tfm_platform_system.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_rng.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_rng_ex.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash_ex.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pka.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp_ex.o [ 10%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/stm/common/hal/Native_Driver/low_level_rng.o [ 10%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_ps.o [ 10%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_its.o [ 10%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_platform.o [ 10%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/uart_stdout.o [ 10%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/faults.o [ 10%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_memory_symbols.o [ 10%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/attest_hal.o [ 11%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/nv_counters.o [ 11%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/crypto_keys.o [ 11%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/tfm_rotpk.o [ 11%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/crypto_nv_seed.o [ 11%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/flash_otp_nv_counters_backend.o [ 11%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/otp_flash.o [ 11%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/provisioning.o [ 11%] Building C object platform/CMakeFiles/platform_s.dir/__/secure_fw/spm/cmsis_psa/psa_interface_cross.o [ 12%] Building C object platform/CMakeFiles/platform_s.dir/__/interface/src/tfm_psa_call_pack.o [ 12%] Linking C static library libplatform_s.a [ 12%] Built target platform_s Scanning dependencies of target tfm_psa_rot_partition_platform [ 12%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/platform_sp.o [ 12%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/generated/secure_fw/partitions/platform/auto_generated/intermedia_tfm_platform.o [ 12%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash.o [ 12%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash_ex.o [ 12%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pka.o [ 12%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp.o [ 13%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp_ex.o [ 13%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/platform/ext/target/stm/common/hal/Native_Driver/low_level_rng.o [ 13%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 13%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 13%] Linking C static library libtfm_psa_rot_partition_platform.a [ 13%] Built target tfm_psa_rot_partition_platform Scanning dependencies of target tfm_psa_rot_partition_its [ 13%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/tfm_its_req_mngr.o [ 13%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/tfm_internal_trusted_storage.o [ 14%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/its_utils.o [ 14%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash.o [ 14%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash_nand.o [ 14%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash_nor.o [ 14%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash_ram.o [ 14%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash_fs/its_flash_fs.o [ 14%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash_fs/its_flash_fs_dblock.o [ 14%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash_fs/its_flash_fs_mblock.o [ 15%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/intermedia_tfm_internal_trusted_storage.o [ 15%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 15%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 15%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash.o [ 15%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash_ex.o [ 15%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pka.o [ 15%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp.o [ 15%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp_ex.o [ 16%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/platform/ext/target/stm/common/hal/Native_Driver/low_level_rng.o [ 16%] Linking C static library libtfm_psa_rot_partition_its.a [ 16%] Built target tfm_psa_rot_partition_its Scanning dependencies of target tfm_app_rot_partition_ps [ 16%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/tfm_ps_req_mngr.o [ 17%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/tfm_protected_storage.o [ 17%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_object_system.o [ 17%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_object_table.o [ 17%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_utils.o [ 17%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/crypto/ps_crypto_interface.o [ 17%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_encrypted_object.o [ 17%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/nv_counters/ps_nv_counters.o [ 17%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/intermedia_tfm_protected_storage.o [ 18%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 18%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 18%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 18%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 18%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 18%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 18%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 20%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/ns_agent_tz/load_info_ns_agent_tz.o [ 20%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/idle_partition/load_info_idle_sp.o [ 20%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash.o [ 20%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash_ex.o [ 20%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pka.o [ 20%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp.o [ 20%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp_ex.o [ 20%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/platform/ext/target/stm/common/hal/Native_Driver/low_level_rng.o [ 21%] Linking C static library libtfm_app_rot_partition_ps.a [ 21%] Built target tfm_app_rot_partition_ps Scanning dependencies of target tfm_psa_rot_partition_attestation [ 21%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest.o [ 21%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest_req_mngr.o [ 21%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_core.o [ 22%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_asymmetric_key.o [ 22%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_token_encode.o [ 22%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/intermedia_tfm_initial_attestation.o [ 22%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 22%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 22%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash.o [ 22%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash_ex.o [ 22%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pka.o [ 23%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp.o [ 23%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp_ex.o [ 23%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/platform/ext/target/stm/common/hal/Native_Driver/low_level_rng.o [ 23%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_sign.o [ 23%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_verify.o [ 23%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_util.o [ 23%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_parameters.o [ 23%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o [ 24%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 24%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 24%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 24%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 24%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 24%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/ns_agent_tz/load_info_ns_agent_tz.o [ 24%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/idle_partition/load_info_idle_sp.o [ 24%] Linking C static library libtfm_psa_rot_partition_attestation.a [ 24%] Built target tfm_psa_rot_partition_attestation [ 25%] Generating version_features.c [ 25%] Generating error.c [ 25%] Generating ssl_debug_helpers_generated.h, ssl_debug_helpers_generated.c Scanning dependencies of target crypto_service_mbedcrypto [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/aes.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/aesni.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/aria.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/asn1parse.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/asn1write.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/base64.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/bignum.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/camellia.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ccm.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/chacha20.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/chachapoly.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/cipher.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/cipher_wrap.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/constant_time.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/cmac.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ctr_drbg.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/des.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/dhm.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecdh.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecdsa.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecjpake.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecp.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecp_curves.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/entropy.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/entropy_poll.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/error.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/gcm.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/hkdf.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/hmac_drbg.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/md.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/md5.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/memory_buffer_alloc.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/mps_reader.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/mps_trace.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/nist_kw.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/oid.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/padlock.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pem.o [ 31%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pk.o [ 31%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pk_wrap.o [ 31%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkcs12.o [ 31%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkcs5.o [ 31%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkparse.o [ 31%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkwrite.o [ 31%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/platform.o [ 31%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/platform_util.o [ 32%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/poly1305.o [ 32%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto.o [ 32%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_aead.o [ 32%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_cipher.o [ 32%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_client.o [ 32%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_driver_wrappers.o [ 32%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_ecp.o [ 32%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_hash.o [ 33%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_mac.o [ 33%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_rsa.o [ 33%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_se.o [ 33%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_slot_management.o [ 33%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_storage.o [ 33%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_its_file.o [ 33%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ripemd160.o [ 33%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/rsa.o [ 34%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/rsa_alt_helpers.o [ 34%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/sha1.o [ 34%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/sha256.o [ 34%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/sha512.o [ 34%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ssl_debug_helpers_generated.o [ 34%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/threading.o [ 34%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/timing.o [ 34%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/version.o [ 35%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/version_features.o [ 35%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/home/a/workspace1/TF-M/trusted-firmware-m/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash.o [ 35%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/home/a/workspace1/TF-M/trusted-firmware-m/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash_ex.o [ 35%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/home/a/workspace1/TF-M/trusted-firmware-m/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pka.o [ 35%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/home/a/workspace1/TF-M/trusted-firmware-m/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp.o [ 35%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/home/a/workspace1/TF-M/trusted-firmware-m/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp_ex.o [ 35%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/home/a/workspace1/TF-M/trusted-firmware-m/platform/ext/target/stm/common/hal/Native_Driver/low_level_rng.o [ 35%] Linking C static library libmbedcrypto.a [ 35%] Built target crypto_service_mbedcrypto Scanning dependencies of target tfm_psa_rot_partition_crypto [ 36%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_init.o [ 36%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_alloc.o [ 36%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_cipher.o [ 36%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_hash.o [ 36%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_mac.o [ 36%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_key.o [ 36%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_aead.o [ 36%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_asymmetric.o [ 37%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_key_derivation.o [ 37%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_key_management.o [ 37%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_rng.o [ 37%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/generated/secure_fw/partitions/crypto/auto_generated/intermedia_tfm_crypto.o [ 37%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 37%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 37%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash.o [ 38%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash_ex.o [ 38%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pka.o [ 38%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp.o [ 38%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp_ex.o [ 38%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/platform/ext/target/stm/common/hal/Native_Driver/low_level_rng.o [ 38%] Linking C static library libtfm_psa_rot_partition_crypto.a [ 38%] Built target tfm_psa_rot_partition_crypto Scanning dependencies of target tfm_sprt [ 38%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memcmp.o [ 38%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memcpy.o [ 38%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memmove.o [ 38%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memset.o [ 38%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_strnlen.o [ 38%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/service_api.o [ 38%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/sprt_partition_metadata_indicator.o [ 40%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/sprt_main.o [ 40%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/sfn_common_thread.o [ 40%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/crypto/tfm_crypto_secure_api.o [ 40%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/initial_attestation/tfm_attest_secure_api.o [ 40%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/protected_storage/tfm_ps_secure_api.o [ 40%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/internal_trusted_storage/tfm_its_secure_api.o [ 40%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/platform/tfm_platform_secure_api.o [ 40%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash.o [ 41%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash_ex.o [ 41%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pka.o [ 41%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp.o [ 41%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp_ex.o [ 41%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/__/platform/ext/target/stm/common/hal/Native_Driver/low_level_rng.o [ 41%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/spm/cmsis_psa/psa_interface_cross.o [ 41%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_psa_call_pack.o [ 41%] Linking C static library libtfm_sprt.a [ 41%] Built target tfm_sprt Scanning dependencies of target tfm_spm [ 41%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/tfm_boot_data.o [ 42%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/tfm_core_utils.o [ 42%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/utilities.o [ 42%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/arch/tfm_arch.o [ 42%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/main.o [ 42%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/spm_ipc.o [ 42%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/spm_cross_call.o [ 42%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/static_load.o [ 42%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/psa_api.o [ 43%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/backend_ipc.o [ 43%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/interrupt.o [ 43%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/tfm_core_svcalls_ipc.o [ 43%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/tfm_pools.o [ 43%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/thread.o [ 43%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ns_client_ext/tfm_spm_ns_ctx.o [ 43%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/arch/tfm_arch_v8m_main.o [ 43%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/ns_agent_tz/ns_agent_tz.o [ 44%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/idle_partition/idle_partition.o [ 44%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash.o [ 44%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash_ex.o [ 44%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pka.o [ 44%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp.o [ 44%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp_ex.o [ 44%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/platform/ext/target/stm/common/hal/Native_Driver/low_level_rng.o [ 44%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/psa_interface_cross.o [ 45%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/interface/src/tfm_psa_call_pack.o [ 45%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 45%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 45%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 45%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 45%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 45%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/ns_agent_tz/load_info_ns_agent_tz.o [ 45%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/idle_partition/load_info_idle_sp.o [ 46%] Linking C static library libtfm_spm.a [ 46%] Built target tfm_spm Scanning dependencies of target tfm_s [ 46%] Building C object secure_fw/CMakeFiles/tfm_s.dir/partitions/ns_agent_tz/tfm_psa_api_veneers.o [ 46%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/stm/common/hal/Native_Driver/tick.o [ 46%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/stm/common/stm32l5xx/Device/Source/startup_stm32l5xx_s.o [ 46%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 46%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 46%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 47%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 47%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 47%] Building C object secure_fw/CMakeFiles/tfm_s.dir/partitions/ns_agent_tz/load_info_ns_agent_tz.o [ 47%] Building C object secure_fw/CMakeFiles/tfm_s.dir/partitions/idle_partition/load_info_idle_sp.o [ 47%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash.o [ 47%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_hash_ex.o [ 47%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pka.o [ 47%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp.o [ 48%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cryp_ex.o [ 48%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/stm/common/hal/Native_Driver/low_level_rng.o [ 48%] Building C object secure_fw/CMakeFiles/tfm_s.dir/spm/cmsis_psa/psa_interface_cross.o [ 48%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/interface/src/tfm_psa_call_pack.o [ 48%] Linking C executable ../bin/tfm_s.axf Memory region Used Size Region Size %age Used FLASH: 150488 B 231 KB 63.62% RAM: 66464 B 127 KB 51.11% [ 48%] Built target tfm_s Scanning dependencies of target tfm_s_hex [ 48%] Generating ../bin/tfm_s.hex [ 48%] Built target tfm_s_hex Scanning dependencies of target tfm_s_bin [ 48%] Generating ../bin/tfm_s.bin [ 48%] Built target tfm_s_bin Scanning dependencies of target tfm_s_elf [ 48%] Generating ../bin/tfm_s.elf [ 48%] Built target tfm_s_elf Scanning dependencies of target tfm_s_binaries [ 48%] Built target tfm_s_binaries [ 48%] Generating s_veneers.o Scanning dependencies of target tfm_s_veneers [ 48%] Generating s_veneers.o [ 48%] Linking C static library libtfm_s_veneers.a [ 48%] Built target tfm_s_veneers Scanning dependencies of target tfm_ns_scatter [ 48%] Building C object platform/target/CMakeFiles/tfm_ns_scatter.dir/__/common/hal/template/gcc/appli_ns.ld [ 48%] Built target tfm_ns_scatter Scanning dependencies of target platform_ns [ 48%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal.o [ 48%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/stm/common/stm32l5xx/Device/Source/Templates/system_stm32l5xx.o [ 48%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/stm/common/hal/CMSIS_Driver/low_level_com.o [ 48%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_dma.o [ 48%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pwr.o [ 48%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_pwr_ex.o [ 48%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_rcc.o [ 50%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_gpio.o [ 50%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_uart.o [ 50%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_uart_ex.o [ 50%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/stm/common/stm32l5xx/hal/Src/stm32l5xx_hal_cortex.o [ 50%] Building C object platform/CMakeFiles/platform_ns.dir/ext/common/uart_stdout.o [ 50%] Linking C static library libplatform_ns.a [ 50%] Built target platform_ns Scanning dependencies of target tfm_api_ns [ 50%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/home/a/workspace1/TF-M/trusted-firmware-m/interface/src/tfm_platform_ipc_api.o [ 51%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/home/a/workspace1/TF-M/trusted-firmware-m/interface/src/tfm_ps_ipc_api.o [ 51%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/home/a/workspace1/TF-M/trusted-firmware-m/interface/src/tfm_its_ipc_api.o [ 51%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/home/a/workspace1/TF-M/trusted-firmware-m/interface/src/tfm_crypto_ipc_api.o [ 51%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/home/a/workspace1/TF-M/trusted-firmware-m/interface/src/tfm_initial_attestation_ipc_api.o [ 51%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/home/a/workspace1/TF-M/trusted-firmware-m/interface/src/tfm_psa_ns_api.o [ 51%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/tfm_ns_interface.o [ 51%] Linking C static library libtfm_api_ns.a [ 51%] Built target tfm_api_ns Scanning dependencies of target psa_generate_database_prerequisite [ 51%] Built target psa_generate_database_prerequisite Scanning dependencies of target psa_generate_database [ 51%] Creating directories for 'psa_generate_database' [ 51%] No download step for 'psa_generate_database' [ 51%] No update step for 'psa_generate_database' [ 51%] No patch step for 'psa_generate_database' [ 52%] Performing configure step for 'psa_generate_database' -- Configuring done -- 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 吴偏偏 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 吴偏偏 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. The build tool we used is gcc-arm-none-eabi-9-2020-q2-update, Cmake 3.19.6, the command lines are as following, mkdir cmake_build cd cmake_build cmake .. -DTFM_PLATFORM=arm/mps2/an521 -DTEST_PSA_API=CRYPTO and the detailed build log is shown below: (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m# mkdir cmake_build (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m# cd cmake_build (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build# cmake .. -DTFM_PLATFORM=arm/mps2/an521 -DTEST_PSA_API=CRYPTO -- Populating tfm_test_repo -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/lib/ext/tfm_test_repo-subbuild Scanning dependencies of target tfm_test_repo-populate [ 11%] Creating directories for 'tfm_test_repo-populate' [ 22%] Performing download step (git clone) for 'tfm_test_repo-populate' Cloning into 'tfm_test_repo-src'... remote: Enumerating objects: 2125, done. remote: Counting objects: 100% (2125/2125), done. remote: Compressing objects: 100% (1167/1167), done. remote: Total 3915 (delta 1881), reused 959 (delta 958), pack-reused 1790 Receiving objects: 100% (3915/3915), 2.34 MiB | 1.35 MiB/s, done. Resolving deltas: 100% (2747/2747), done. Checking connectivity... done. Note: checking out '723905d'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at 723905d... Test: Fix bug in BL1 TRNG testsuite [ 33%] Performing update step for 'tfm_test_repo-populate' [ 44%] No patch step for 'tfm_test_repo-populate' [ 55%] No configure step for 'tfm_test_repo-populate' [ 66%] No build step for 'tfm_test_repo-populate' [ 77%] No install step for 'tfm_test_repo-populate' [ 88%] No test step for 'tfm_test_repo-populate' [100%] Completed 'tfm_test_repo-populate' [100%] Built target tfm_test_repo-populate -- The C compiler identification is GNU 9.3.1 -- The ASM compiler identification is GNU -- Found assembler: /home/a/Tools/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc -- Found Git: /usr/bin/git (found version "2.7.4") -- Populating mbedcrypto -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/lib/ext/mbedcrypto-subbuild Scanning dependencies of target mbedcrypto-populate [ 11%] Creating directories for 'mbedcrypto-populate' [ 22%] Performing download step (git clone) for 'mbedcrypto-populate' Cloning into 'mbedcrypto-src'... remote: Enumerating objects: 24752, done. remote: Counting objects: 100% (24752/24752), done. remote: Compressing objects: 100% (12192/12192), done. remote: Total 24752 (delta 19476), reused 16609 (delta 12385), pack-reused 0 Receiving objects: 100% (24752/24752), 27.22 MiB | 193.00 KiB/s, done. Resolving deltas: 100% (19476/19476), done. Checking connectivity... done. Note: checking out 'mbedtls-3.1.0'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at d65aeb3... Merge pull request #871 from ronald-cron-arm/mbedtls-3.1.0rc0-pr [ 33%] Performing update step for 'mbedcrypto-populate' [ 44%] Performing patch step for 'mbedcrypto-populate' [ 55%] No configure step for 'mbedcrypto-populate' [ 66%] No build step for 'mbedcrypto-populate' [ 77%] No install step for 'mbedcrypto-populate' [ 88%] No test step for 'mbedcrypto-populate' [100%] Completed 'mbedcrypto-populate' [100%] Built target mbedcrypto-populate -- Populating mcuboot -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/lib/ext/mcuboot-subbuild Scanning dependencies of target mcuboot-populate [ 11%] Creating directories for 'mcuboot-populate' [ 22%] Performing download step (git clone) for 'mcuboot-populate' Cloning into 'mcuboot-src'... remote: Enumerating objects: 15238, done. remote: Counting objects: 100% (97/97), done. remote: Compressing objects: 100% (72/72), done. remote: Total 15238 (delta 25), reused 56 (delta 20), pack-reused 15141 Receiving objects: 100% (15238/15238), 5.39 MiB | 2.06 MiB/s, done. Resolving deltas: 100% (9918/9918), done. Checking connectivity... done. Note: checking out 'v1.9.0'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at c657cbe... Update to version 1.9.0 [ 33%] Performing update step for 'mcuboot-populate' [ 44%] No patch step for 'mcuboot-populate' [ 55%] No configure step for 'mcuboot-populate' [ 66%] No build step for 'mcuboot-populate' [ 77%] No install step for 'mcuboot-populate' [ 88%] No test step for 'mcuboot-populate' [100%] Completed 'mcuboot-populate' [100%] Built target mcuboot-populate -- Populating psa_arch_tests -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/lib/ext/psa_arch_tests-subbuild Scanning dependencies of target psa_arch_tests-populate [ 11%] Creating directories for 'psa_arch_tests-populate' [ 22%] Performing download step (git clone) for 'psa_arch_tests-populate' Cloning into 'psa_arch_tests-src'... remote: Enumerating objects: 12584, done. remote: Counting objects: 100% (497/497), done. remote: Compressing objects: 100% (219/219), done. remote: Total 12584 (delta 321), reused 353 (delta 277), pack-reused 12087 Receiving objects: 100% (12584/12584), 17.82 MiB | 2.50 MiB/s, done. Resolving deltas: 100% (9416/9416), done. Checking connectivity... done. Note: checking out 'f7e8495'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at f7e8495... Merge pull request #317 from joerchan/tfm-fix-wdt-timeout [ 33%] Performing update step for 'psa_arch_tests-populate' [ 44%] Performing patch step for 'psa_arch_tests-populate' [ 55%] No configure step for 'psa_arch_tests-populate' [ 66%] No build step for 'psa_arch_tests-populate' [ 77%] No install step for 'psa_arch_tests-populate' [ 88%] No test step for 'psa_arch_tests-populate' [100%] Completed 'psa_arch_tests-populate' [100%] Built target psa_arch_tests-populate -- Found Python3: /home/a/python3.6/bin/python3.6 (found version "3.6.12") found components: Interpreter Start to generate partition files: Generating Protected Storage Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/protected_storage Generating TF-M Internal Trusted Storage Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/internal_trusted_storage Generating TFM Crypto Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/crypto Generating TFM Platform Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/platform Generating TFM Initial Attestation Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/initial_attestation Per-partition files done: -- ---------- Display crypto configuration - start -------------- -- CRYPTO_RNG_MODULE_DISABLED is set to FALSE -- CRYPTO_KEY_MODULE_DISABLED is set to FALSE -- CRYPTO_AEAD_MODULE_DISABLED is set to FALSE -- CRYPTO_MAC_MODULE_DISABLED is set to FALSE -- CRYPTO_CIPHER_MODULE_DISABLED is set to FALSE -- CRYPTO_HASH_MODULE_DISABLED is set to FALSE -- CRYPTO_KEY_DERIVATION_MODULE_DISABLED is set to FALSE -- CRYPTO_ASYM_SIGN_MODULE_DISABLED is set to FALSE -- CRYPTO_ASYM_ENCRYPT_MODULE_DISABLED is set to FALSE -- CRYPTO_ENGINE_BUF_SIZE is set to 0x5000 -- CRYPTO_CONC_OPER_NUM is set to 8 -- CRYPTO_IOVEC_BUFFER_SIZE is set to 5120 -- ---------- Display crypto configuration - stop --------------- -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS - Failed -- Found Perl: /usr/bin/perl (found version "5.22.1") -- ----------- Display storage configuration - start ------------ -- PS_CREATE_FLASH_LAYOUT is set to ON -- PS_ENCRYPTION is set to ON -- PS_RAM_FS is set to OFF -- PS_ROLLBACK_PROTECTION is set to ON -- PS_VALIDATE_METADATA_FROM_FLASH is set to ON -- PS_MAX_ASSET_SIZE is set to 2048 -- PS_NUM_ASSETS is set to 10 -- PS_CRYPTO_AEAD_ALG is set to PSA_ALG_GCM -- ITS_CREATE_FLASH_LAYOUT is set to ON -- ITS_RAM_FS is set to OFF -- ITS_VALIDATE_METADATA_FROM_FLASH is set to ON -- ITS_MAX_ASSET_SIZE is set to 1229 -- ITS_NUM_ASSETS is set to 10 -- ITS_BUF_SIZE is not set (defaults to ITS_MAX_ASSET_SIZE) -- ----------- Display storage configuration - stop ------------- -- Found PythonInterp: /home/a/python3.6/bin/python3 (found suitable version "3.6.12", minimum required is "3") -- [PSA] : ----------Process input arguments- start------------- -- [PSA] : TARGET is set to tgt_dev_apis_tfm_an521 -- [PSA] : SUITE is set to CRYPTO -- [PSA] : TOOLCHAIN is set to GNUARM -- [PSA] : CPU_ARCH is set to armv8m_ml -- [PSA] : Defaulting VERBOSE to 3 -- [PSA] : Defaulting INCLUDE_PANIC_TESTS to 0 -- [PSA] : Defaulting WATCHDOG_AVAILABLE to 1 -- [PSA] : Default spec version -- [PSA] : Defaulting TESTS_COVERAGE to ALL -- [PSA] : ----------Process input arguments- complete------------- -- [PSA] : Creating testlist.txt 'available at /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/crypto_testlist.txt' Non-secure test entry symbol list: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/test_entry_list.inc, /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/test_entry_fn_declare_list.inc -- [PSA] : C compiler used '/home/a/Tools/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc' -- [PSA] : ASM compiler used '/home/a/Tools/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc' -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build# make install Scanning dependencies of target tfm_fih_implementation [ 0%] Building C object lib/fih/CMakeFiles/tfm_fih_implementation.dir/src/fih.o [ 1%] Linking C static library libtfm_fih_implementation.a [ 1%] Built target tfm_fih_implementation Scanning dependencies of target tfm_generated_files [ 1%] Built target tfm_generated_files Scanning dependencies of target tfm_s_scatter [ 1%] Building C object platform/target/CMakeFiles/tfm_s_scatter.dir/__/__/__/__/common/gcc/tfm_common_s.ld [ 1%] Built target tfm_s_scatter Scanning dependencies of target tfm_qcbor_s [ 2%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/ieee754.o [ 2%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/qcbor_encode.o [ 2%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/qcbor_decode.o [ 2%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/UsefulBuf.o [ 2%] Linking C static library libtfm_qcbor_s.a [ 2%] Built target tfm_qcbor_s Scanning dependencies of target tfm_t_cose_s [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_sign1_sign.o [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_sign1_verify.o [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_util.o [ 3%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_parameters.o [ 3%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/crypto_adapters/t_cose_psa_crypto.o [ 3%] Linking C static library libtfm_t_cose_s.a [ 3%] Built target tfm_t_cose_s Scanning dependencies of target platform_s [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_Flash.o [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_MPC.o [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_PPC.o [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_USART.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/retarget/platform_retarget_dev.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_core/system_cmsdk_mps2_an521.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/mpc_sie200_drv.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/mpu_armv8m_drv.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/ppc_sse200_drv.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/spm_hal.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/tfm_interrupts.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/tfm_hal_isolation.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/tfm_hal_platform.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/target_cfg.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/arm_uart_drv.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/timer_cmsdk/timer_cmsdk.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_nvic.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_isolation_mpu_v8m.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/services/src/tfm_platform_system.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_ps.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_its.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_platform.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/uart_stdout.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/faults.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_memory_symbols.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/attest_hal.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/nv_counters.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/crypto_keys.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/tfm_rotpk.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/crypto_nv_seed.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/flash_otp_nv_counters_backend.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/otp_flash.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/provisioning.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/__/secure_fw/spm/cmsis_psa/psa_interface_cross.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/__/interface/src/tfm_psa_call_pack.o [ 9%] Linking C static library libplatform_s.a [ 9%] Built target platform_s Scanning dependencies of target tfm_psa_rot_partition_platform [ 9%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/platform_sp.o [ 9%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/generated/secure_fw/partitions/platform/auto_generated/intermedia_tfm_platform.o [ 9%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 9%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 9%] Linking C static library libtfm_psa_rot_partition_platform.a [ 9%] Built target tfm_psa_rot_partition_platform Scanning dependencies of target tfm_psa_rot_partition_its [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/tfm_its_req_mngr.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/tfm_internal_trusted_storage.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/its_utils.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash_nand.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash_nor.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash_ram.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash_fs/its_flash_fs.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash_fs/its_flash_fs_dblock.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash_fs/its_flash_fs_mblock.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/intermedia_tfm_internal_trusted_storage.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 12%] Linking C static library libtfm_psa_rot_partition_its.a [ 12%] Built target tfm_psa_rot_partition_its Scanning dependencies of target tfm_app_rot_partition_ps [ 12%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/tfm_ps_req_mngr.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/tfm_protected_storage.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_object_system.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_object_table.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_utils.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/crypto/ps_crypto_interface.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_encrypted_object.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/nv_counters/ps_nv_counters.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/intermedia_tfm_protected_storage.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/ns_agent_tz/load_info_ns_agent_tz.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/idle_partition/load_info_idle_sp.o [ 15%] Linking C static library libtfm_app_rot_partition_ps.a [ 15%] Built target tfm_app_rot_partition_ps Scanning dependencies of target tfm_psa_rot_partition_attestation [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest.o [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest_req_mngr.o [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_core.o [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_asymmetric_key.o [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_token_encode.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/intermedia_tfm_initial_attestation.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_sign.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_verify.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_util.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_parameters.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 19%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/ns_agent_tz/load_info_ns_agent_tz.o [ 19%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/idle_partition/load_info_idle_sp.o [ 19%] Linking C static library libtfm_psa_rot_partition_attestation.a [ 19%] Built target tfm_psa_rot_partition_attestation [ 19%] Generating version_features.c [ 19%] Generating error.c [ 19%] Generating ssl_debug_helpers_generated.h, ssl_debug_helpers_generated.c Scanning dependencies of target crypto_service_mbedcrypto [ 19%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/aes.o [ 19%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/aesni.o [ 19%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/aria.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/asn1parse.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/asn1write.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/base64.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/bignum.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/camellia.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ccm.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/chacha20.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/chachapoly.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/cipher.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/cipher_wrap.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/constant_time.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/cmac.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ctr_drbg.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/des.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/dhm.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecdh.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecdsa.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecjpake.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecp.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecp_curves.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/entropy.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/entropy_poll.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/error.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/gcm.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/hkdf.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/hmac_drbg.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/md.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/md5.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/memory_buffer_alloc.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/mps_reader.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/mps_trace.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/nist_kw.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/oid.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/padlock.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pem.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pk.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pk_wrap.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkcs12.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkcs5.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkparse.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkwrite.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/platform.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/platform_util.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/poly1305.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_aead.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_cipher.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_client.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_driver_wrappers.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_ecp.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_hash.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_mac.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_rsa.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_se.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_slot_management.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_storage.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_its_file.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ripemd160.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/rsa.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/rsa_alt_helpers.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/sha1.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/sha256.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/sha512.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ssl_debug_helpers_generated.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/threading.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/timing.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/version.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/version_features.o [ 31%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/__/__/__/__/__/secure_fw/partitions/crypto/tfm_mbedcrypto_alt.o [ 31%] Linking C static library libmbedcrypto.a [ 31%] Built target crypto_service_mbedcrypto Scanning dependencies of target tfm_psa_rot_partition_crypto [ 31%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_init.o [ 31%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_alloc.o [ 31%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_cipher.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_hash.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_mac.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_key.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_aead.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_asymmetric.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_key_derivation.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_key_management.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_rng.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/generated/secure_fw/partitions/crypto/auto_generated/intermedia_tfm_crypto.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 34%] Linking C static library libtfm_psa_rot_partition_crypto.a [ 34%] Built target tfm_psa_rot_partition_crypto Scanning dependencies of target tfm_sprt [ 34%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memcmp.o [ 34%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memcpy.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memmove.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memset.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_strnlen.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/service_api.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/sprt_partition_metadata_indicator.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/sprt_main.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/sfn_common_thread.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/crypto/tfm_crypto_secure_api.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/initial_attestation/tfm_attest_secure_api.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/protected_storage/tfm_ps_secure_api.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/internal_trusted_storage/tfm_its_secure_api.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/platform/tfm_platform_secure_api.o [ 37%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/spm/cmsis_psa/psa_interface_cross.o [ 37%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_psa_call_pack.o [ 37%] Linking C static library libtfm_sprt.a [ 37%] Built target tfm_sprt Scanning dependencies of target tfm_spm [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/tfm_boot_data.o [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/tfm_core_utils.o [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/utilities.o [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/arch/tfm_arch.o [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/main.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/spm_ipc.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/spm_cross_call.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/static_load.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/psa_api.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/backend_ipc.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/interrupt.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/tfm_core_svcalls_ipc.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/tfm_pools.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/thread.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ns_client_ext/tfm_spm_ns_ctx.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/arch/tfm_arch_v8m_main.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/ns_agent_tz/ns_agent_tz.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/idle_partition/idle_partition.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/psa_interface_cross.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/interface/src/tfm_psa_call_pack.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 41%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 41%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 41%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/ns_agent_tz/load_info_ns_agent_tz.o [ 41%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/idle_partition/load_info_idle_sp.o [ 41%] Linking C static library libtfm_spm.a [ 41%] Built target tfm_spm Scanning dependencies of target tfm_s [ 41%] Building C object secure_fw/CMakeFiles/tfm_s.dir/partitions/ns_agent_tz/tfm_psa_api_veneers.o [ 42%] Building ASM object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/arm/mps2/an521/gcc/startup_cmsdk_mps2_an521_s.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 43%] Building C object secure_fw/CMakeFiles/tfm_s.dir/partitions/ns_agent_tz/load_info_ns_agent_tz.o [ 43%] Building C object secure_fw/CMakeFiles/tfm_s.dir/partitions/idle_partition/load_info_idle_sp.o [ 43%] Building C object secure_fw/CMakeFiles/tfm_s.dir/spm/cmsis_psa/psa_interface_cross.o [ 43%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/interface/src/tfm_psa_call_pack.o [ 43%] Linking C executable ../bin/tfm_s.axf Memory region Used Size Region Size %age Used FLASH: 140584 B 446 KB 30.78% RAM: 73792 B 1 MB 7.04% [ 43%] Built target tfm_s Scanning dependencies of target tfm_s_hex [ 43%] Generating ../bin/tfm_s.hex [ 43%] Built target tfm_s_hex Scanning dependencies of target tfm_s_bin [ 43%] Generating ../bin/tfm_s.bin [ 43%] Built target tfm_s_bin Scanning dependencies of target tfm_s_elf [ 44%] Generating ../bin/tfm_s.elf [ 44%] Built target tfm_s_elf Scanning dependencies of target tfm_s_binaries [ 44%] Built target tfm_s_binaries [ 44%] Generating s_veneers.o Scanning dependencies of target tfm_s_veneers [ 44%] Generating s_veneers.o [ 45%] Linking C static library libtfm_s_veneers.a [ 45%] Built target tfm_s_veneers Scanning dependencies of target tfm_ns_scatter [ 45%] Building C object platform/target/CMakeFiles/tfm_ns_scatter.dir/gcc/mps2_an521_ns.ld [ 45%] Built target tfm_ns_scatter Scanning dependencies of target platform_ns [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/native_drivers/arm_uart_drv.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/native_drivers/timer_cmsdk/timer_cmsdk.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_USART.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/retarget/platform_retarget_dev.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/cmsis_core/system_cmsdk_mps2_an521.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/plat_test.o [ 47%] Building C object platform/CMakeFiles/platform_ns.dir/ext/common/uart_stdout.o [ 47%] Linking C static library libplatform_ns.a [ 47%] Built target platform_ns Scanning dependencies of target tfm_api_ns [ 47%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_platform_ipc_api.o [ 47%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_ps_ipc_api.o [ 47%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_its_ipc_api.o [ 48%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_crypto_ipc_api.o [ 48%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_initial_attestation_ipc_api.o [ 48%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_psa_ns_api.o [ 48%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/tfm_ns_interface.o [ 48%] Linking C static library libtfm_api_ns.a [ 48%] Built target tfm_api_ns Scanning dependencies of target psa_generate_database_prerequisite [ 48%] Built target psa_generate_database_prerequisite Scanning dependencies of target psa_generate_database [ 48%] Creating directories for 'psa_generate_database' [ 48%] No download step for 'psa_generate_database' [ 48%] No update step for 'psa_generate_database' [ 48%] No patch step for 'psa_generate_database' [ 50%] Performing configure step for 'psa_generate_database' -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/src/psa_generate_database-build [ 50%] No build step for 'psa_generate_database' [ 50%] Performing install step for 'psa_generate_database' [ 20%] [PSA] : Creating generator source /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/targetConfigGen.c Scanning dependencies of target TargetConfigGen [ 40%] Building C object CMakeFiles/TargetConfigGen.dir/home/a/workspace1/TF-M/trustedfirmware-m/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/trustedfirmware-m/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/trustedfirmware-m/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:1862: 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 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 吴偏偏 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

3 years, 4 months

5
5
0 0

Non-OSI license issue with QCBOR

by Kevin Townsend

We were discussing a problem with the Zephyr integration of TF-M today on the Zephyr TSC call, determining how to avoid QCBOR being downloaded at build time, which is against Zephyr project policy. Zephyr project policy is that all build dependencies need to exist in the Zephyr project Github org, and be downloaded before building. During the discussion, it came up that QCBOR actually doesn't have an OSI approved open license, even if it appears to have one on first glance: https://github.com/zephyrproject-rtos/zephyr/issues/54017#issuecomment-1422… "Essentially" 3-Clause BSD really doesn't legally mean anything https://github.com/laurencelundblade/QCBOR/blob/master/README.md?plain=1#L5… It looks like `NON-INFRINGEMENT` has been added to the license text, which is easy to miss, but entirely changes the license terms. This is highly problematic, since not being OSI compliant now puts us in a position where we may have to remove TF-M from Zephyr to avoid blocking the 3.3 release, due to project policy around licenses, or I need to remove anything that relies on QCBOR until the license can be sorted out, with the 3.3 release and freeze scheduled for Friday. I'll look tomorrow at disabling attestation tokens, which seem to be the main user of this, but I wanted to bring the license issues up for anyone else who requires OSI-complliant licenses since this is easy to miss, and has been missed until now days from a release. Thought it was important enough to quickly bring up here for TSC attention, while I try to find a solution less radical that removing TF-M to avoid blocking the Zephyr release. -- Thanks and best regards, Kevin Townsend Tech Lead - LITE, Vertical Technologies Linaro.org │ Open source software for ARM SoCs

3 years, 4 months

6
7
0 0

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

by Edward Yang

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 吴偏偏 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. The build tool we used is gcc-arm-none-eabi-9-2020-q2-update, Cmake 3.19.6, the command lines are as following, mkdir cmake_build cd cmake_build cmake .. -DTFM_PLATFORM=arm/mps2/an521 -DTEST_PSA_API=CRYPTO and the detailed build log is shown below: (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m# mkdir cmake_build (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m# cd cmake_build (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build# cmake .. -DTFM_PLATFORM=arm/mps2/an521 -DTEST_PSA_API=CRYPTO -- Populating tfm_test_repo -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/lib/ext/tfm_test_repo-subbuild Scanning dependencies of target tfm_test_repo-populate [ 11%] Creating directories for 'tfm_test_repo-populate' [ 22%] Performing download step (git clone) for 'tfm_test_repo-populate' Cloning into 'tfm_test_repo-src'... remote: Enumerating objects: 2125, done. remote: Counting objects: 100% (2125/2125), done. remote: Compressing objects: 100% (1167/1167), done. remote: Total 3915 (delta 1881), reused 959 (delta 958), pack-reused 1790 Receiving objects: 100% (3915/3915), 2.34 MiB | 1.35 MiB/s, done. Resolving deltas: 100% (2747/2747), done. Checking connectivity... done. Note: checking out '723905d'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at 723905d... Test: Fix bug in BL1 TRNG testsuite [ 33%] Performing update step for 'tfm_test_repo-populate' [ 44%] No patch step for 'tfm_test_repo-populate' [ 55%] No configure step for 'tfm_test_repo-populate' [ 66%] No build step for 'tfm_test_repo-populate' [ 77%] No install step for 'tfm_test_repo-populate' [ 88%] No test step for 'tfm_test_repo-populate' [100%] Completed 'tfm_test_repo-populate' [100%] Built target tfm_test_repo-populate -- The C compiler identification is GNU 9.3.1 -- The ASM compiler identification is GNU -- Found assembler: /home/a/Tools/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc -- Found Git: /usr/bin/git (found version "2.7.4") -- Populating mbedcrypto -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/lib/ext/mbedcrypto-subbuild Scanning dependencies of target mbedcrypto-populate [ 11%] Creating directories for 'mbedcrypto-populate' [ 22%] Performing download step (git clone) for 'mbedcrypto-populate' Cloning into 'mbedcrypto-src'... remote: Enumerating objects: 24752, done. remote: Counting objects: 100% (24752/24752), done. remote: Compressing objects: 100% (12192/12192), done. remote: Total 24752 (delta 19476), reused 16609 (delta 12385), pack-reused 0 Receiving objects: 100% (24752/24752), 27.22 MiB | 193.00 KiB/s, done. Resolving deltas: 100% (19476/19476), done. Checking connectivity... done. Note: checking out 'mbedtls-3.1.0'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at d65aeb3... Merge pull request #871 from ronald-cron-arm/mbedtls-3.1.0rc0-pr [ 33%] Performing update step for 'mbedcrypto-populate' [ 44%] Performing patch step for 'mbedcrypto-populate' [ 55%] No configure step for 'mbedcrypto-populate' [ 66%] No build step for 'mbedcrypto-populate' [ 77%] No install step for 'mbedcrypto-populate' [ 88%] No test step for 'mbedcrypto-populate' [100%] Completed 'mbedcrypto-populate' [100%] Built target mbedcrypto-populate -- Populating mcuboot -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/lib/ext/mcuboot-subbuild Scanning dependencies of target mcuboot-populate [ 11%] Creating directories for 'mcuboot-populate' [ 22%] Performing download step (git clone) for 'mcuboot-populate' Cloning into 'mcuboot-src'... remote: Enumerating objects: 15238, done. remote: Counting objects: 100% (97/97), done. remote: Compressing objects: 100% (72/72), done. remote: Total 15238 (delta 25), reused 56 (delta 20), pack-reused 15141 Receiving objects: 100% (15238/15238), 5.39 MiB | 2.06 MiB/s, done. Resolving deltas: 100% (9918/9918), done. Checking connectivity... done. Note: checking out 'v1.9.0'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at c657cbe... Update to version 1.9.0 [ 33%] Performing update step for 'mcuboot-populate' [ 44%] No patch step for 'mcuboot-populate' [ 55%] No configure step for 'mcuboot-populate' [ 66%] No build step for 'mcuboot-populate' [ 77%] No install step for 'mcuboot-populate' [ 88%] No test step for 'mcuboot-populate' [100%] Completed 'mcuboot-populate' [100%] Built target mcuboot-populate -- Populating psa_arch_tests -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/lib/ext/psa_arch_tests-subbuild Scanning dependencies of target psa_arch_tests-populate [ 11%] Creating directories for 'psa_arch_tests-populate' [ 22%] Performing download step (git clone) for 'psa_arch_tests-populate' Cloning into 'psa_arch_tests-src'... remote: Enumerating objects: 12584, done. remote: Counting objects: 100% (497/497), done. remote: Compressing objects: 100% (219/219), done. remote: Total 12584 (delta 321), reused 353 (delta 277), pack-reused 12087 Receiving objects: 100% (12584/12584), 17.82 MiB | 2.50 MiB/s, done. Resolving deltas: 100% (9416/9416), done. Checking connectivity... done. Note: checking out 'f7e8495'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at f7e8495... Merge pull request #317 from joerchan/tfm-fix-wdt-timeout [ 33%] Performing update step for 'psa_arch_tests-populate' [ 44%] Performing patch step for 'psa_arch_tests-populate' [ 55%] No configure step for 'psa_arch_tests-populate' [ 66%] No build step for 'psa_arch_tests-populate' [ 77%] No install step for 'psa_arch_tests-populate' [ 88%] No test step for 'psa_arch_tests-populate' [100%] Completed 'psa_arch_tests-populate' [100%] Built target psa_arch_tests-populate -- Found Python3: /home/a/python3.6/bin/python3.6 (found version "3.6.12") found components: Interpreter Start to generate partition files: Generating Protected Storage Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/protected_storage Generating TF-M Internal Trusted Storage Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/internal_trusted_storage Generating TFM Crypto Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/crypto Generating TFM Platform Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/platform Generating TFM Initial Attestation Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/initial_attestation Per-partition files done: -- ---------- Display crypto configuration - start -------------- -- CRYPTO_RNG_MODULE_DISABLED is set to FALSE -- CRYPTO_KEY_MODULE_DISABLED is set to FALSE -- CRYPTO_AEAD_MODULE_DISABLED is set to FALSE -- CRYPTO_MAC_MODULE_DISABLED is set to FALSE -- CRYPTO_CIPHER_MODULE_DISABLED is set to FALSE -- CRYPTO_HASH_MODULE_DISABLED is set to FALSE -- CRYPTO_KEY_DERIVATION_MODULE_DISABLED is set to FALSE -- CRYPTO_ASYM_SIGN_MODULE_DISABLED is set to FALSE -- CRYPTO_ASYM_ENCRYPT_MODULE_DISABLED is set to FALSE -- CRYPTO_ENGINE_BUF_SIZE is set to 0x5000 -- CRYPTO_CONC_OPER_NUM is set to 8 -- CRYPTO_IOVEC_BUFFER_SIZE is set to 5120 -- ---------- Display crypto configuration - stop --------------- -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS - Failed -- Found Perl: /usr/bin/perl (found version "5.22.1") -- ----------- Display storage configuration - start ------------ -- PS_CREATE_FLASH_LAYOUT is set to ON -- PS_ENCRYPTION is set to ON -- PS_RAM_FS is set to OFF -- PS_ROLLBACK_PROTECTION is set to ON -- PS_VALIDATE_METADATA_FROM_FLASH is set to ON -- PS_MAX_ASSET_SIZE is set to 2048 -- PS_NUM_ASSETS is set to 10 -- PS_CRYPTO_AEAD_ALG is set to PSA_ALG_GCM -- ITS_CREATE_FLASH_LAYOUT is set to ON -- ITS_RAM_FS is set to OFF -- ITS_VALIDATE_METADATA_FROM_FLASH is set to ON -- ITS_MAX_ASSET_SIZE is set to 1229 -- ITS_NUM_ASSETS is set to 10 -- ITS_BUF_SIZE is not set (defaults to ITS_MAX_ASSET_SIZE) -- ----------- Display storage configuration - stop ------------- -- Found PythonInterp: /home/a/python3.6/bin/python3 (found suitable version "3.6.12", minimum required is "3") -- [PSA] : ----------Process input arguments- start------------- -- [PSA] : TARGET is set to tgt_dev_apis_tfm_an521 -- [PSA] : SUITE is set to CRYPTO -- [PSA] : TOOLCHAIN is set to GNUARM -- [PSA] : CPU_ARCH is set to armv8m_ml -- [PSA] : Defaulting VERBOSE to 3 -- [PSA] : Defaulting INCLUDE_PANIC_TESTS to 0 -- [PSA] : Defaulting WATCHDOG_AVAILABLE to 1 -- [PSA] : Default spec version -- [PSA] : Defaulting TESTS_COVERAGE to ALL -- [PSA] : ----------Process input arguments- complete------------- -- [PSA] : Creating testlist.txt 'available at /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/crypto_testlist.txt' Non-secure test entry symbol list: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/test_entry_list.inc, /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/test_entry_fn_declare_list.inc -- [PSA] : C compiler used '/home/a/Tools/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc' -- [PSA] : ASM compiler used '/home/a/Tools/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc' -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build# make install Scanning dependencies of target tfm_fih_implementation [ 0%] Building C object lib/fih/CMakeFiles/tfm_fih_implementation.dir/src/fih.o [ 1%] Linking C static library libtfm_fih_implementation.a [ 1%] Built target tfm_fih_implementation Scanning dependencies of target tfm_generated_files [ 1%] Built target tfm_generated_files Scanning dependencies of target tfm_s_scatter [ 1%] Building C object platform/target/CMakeFiles/tfm_s_scatter.dir/__/__/__/__/common/gcc/tfm_common_s.ld [ 1%] Built target tfm_s_scatter Scanning dependencies of target tfm_qcbor_s [ 2%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/ieee754.o [ 2%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/qcbor_encode.o [ 2%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/qcbor_decode.o [ 2%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/UsefulBuf.o [ 2%] Linking C static library libtfm_qcbor_s.a [ 2%] Built target tfm_qcbor_s Scanning dependencies of target tfm_t_cose_s [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_sign1_sign.o [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_sign1_verify.o [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_util.o [ 3%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_parameters.o [ 3%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/crypto_adapters/t_cose_psa_crypto.o [ 3%] Linking C static library libtfm_t_cose_s.a [ 3%] Built target tfm_t_cose_s Scanning dependencies of target platform_s [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_Flash.o [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_MPC.o [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_PPC.o [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_USART.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/retarget/platform_retarget_dev.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_core/system_cmsdk_mps2_an521.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/mpc_sie200_drv.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/mpu_armv8m_drv.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/ppc_sse200_drv.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/spm_hal.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/tfm_interrupts.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/tfm_hal_isolation.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/tfm_hal_platform.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/target_cfg.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/arm_uart_drv.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/timer_cmsdk/timer_cmsdk.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_nvic.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_isolation_mpu_v8m.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/services/src/tfm_platform_system.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_ps.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_its.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_platform.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/uart_stdout.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/faults.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_memory_symbols.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/attest_hal.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/nv_counters.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/crypto_keys.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/tfm_rotpk.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/crypto_nv_seed.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/flash_otp_nv_counters_backend.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/otp_flash.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/provisioning.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/__/secure_fw/spm/cmsis_psa/psa_interface_cross.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/__/interface/src/tfm_psa_call_pack.o [ 9%] Linking C static library libplatform_s.a [ 9%] Built target platform_s Scanning dependencies of target tfm_psa_rot_partition_platform [ 9%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/platform_sp.o [ 9%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/generated/secure_fw/partitions/platform/auto_generated/intermedia_tfm_platform.o [ 9%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 9%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 9%] Linking C static library libtfm_psa_rot_partition_platform.a [ 9%] Built target tfm_psa_rot_partition_platform Scanning dependencies of target tfm_psa_rot_partition_its [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/tfm_its_req_mngr.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/tfm_internal_trusted_storage.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/its_utils.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash_nand.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash_nor.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash_ram.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash_fs/its_flash_fs.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash_fs/its_flash_fs_dblock.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash_fs/its_flash_fs_mblock.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/intermedia_tfm_internal_trusted_storage.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 12%] Linking C static library libtfm_psa_rot_partition_its.a [ 12%] Built target tfm_psa_rot_partition_its Scanning dependencies of target tfm_app_rot_partition_ps [ 12%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/tfm_ps_req_mngr.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/tfm_protected_storage.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_object_system.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_object_table.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_utils.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/crypto/ps_crypto_interface.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_encrypted_object.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/nv_counters/ps_nv_counters.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/intermedia_tfm_protected_storage.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/ns_agent_tz/load_info_ns_agent_tz.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/idle_partition/load_info_idle_sp.o [ 15%] Linking C static library libtfm_app_rot_partition_ps.a [ 15%] Built target tfm_app_rot_partition_ps Scanning dependencies of target tfm_psa_rot_partition_attestation [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest.o [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest_req_mngr.o [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_core.o [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_asymmetric_key.o [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_token_encode.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/intermedia_tfm_initial_attestation.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_sign.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_verify.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_util.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_parameters.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 19%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/ns_agent_tz/load_info_ns_agent_tz.o [ 19%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/idle_partition/load_info_idle_sp.o [ 19%] Linking C static library libtfm_psa_rot_partition_attestation.a [ 19%] Built target tfm_psa_rot_partition_attestation [ 19%] Generating version_features.c [ 19%] Generating error.c [ 19%] Generating ssl_debug_helpers_generated.h, ssl_debug_helpers_generated.c Scanning dependencies of target crypto_service_mbedcrypto [ 19%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/aes.o [ 19%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/aesni.o [ 19%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/aria.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/asn1parse.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/asn1write.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/base64.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/bignum.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/camellia.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ccm.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/chacha20.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/chachapoly.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/cipher.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/cipher_wrap.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/constant_time.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/cmac.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ctr_drbg.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/des.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/dhm.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecdh.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecdsa.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecjpake.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecp.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecp_curves.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/entropy.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/entropy_poll.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/error.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/gcm.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/hkdf.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/hmac_drbg.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/md.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/md5.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/memory_buffer_alloc.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/mps_reader.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/mps_trace.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/nist_kw.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/oid.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/padlock.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pem.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pk.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pk_wrap.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkcs12.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkcs5.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkparse.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkwrite.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/platform.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/platform_util.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/poly1305.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_aead.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_cipher.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_client.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_driver_wrappers.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_ecp.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_hash.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_mac.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_rsa.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_se.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_slot_management.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_storage.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_its_file.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ripemd160.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/rsa.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/rsa_alt_helpers.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/sha1.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/sha256.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/sha512.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ssl_debug_helpers_generated.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/threading.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/timing.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/version.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/version_features.o [ 31%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/__/__/__/__/__/secure_fw/partitions/crypto/tfm_mbedcrypto_alt.o [ 31%] Linking C static library libmbedcrypto.a [ 31%] Built target crypto_service_mbedcrypto Scanning dependencies of target tfm_psa_rot_partition_crypto [ 31%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_init.o [ 31%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_alloc.o [ 31%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_cipher.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_hash.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_mac.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_key.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_aead.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_asymmetric.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_key_derivation.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_key_management.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_rng.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/generated/secure_fw/partitions/crypto/auto_generated/intermedia_tfm_crypto.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 34%] Linking C static library libtfm_psa_rot_partition_crypto.a [ 34%] Built target tfm_psa_rot_partition_crypto Scanning dependencies of target tfm_sprt [ 34%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memcmp.o [ 34%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memcpy.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memmove.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memset.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_strnlen.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/service_api.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/sprt_partition_metadata_indicator.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/sprt_main.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/sfn_common_thread.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/crypto/tfm_crypto_secure_api.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/initial_attestation/tfm_attest_secure_api.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/protected_storage/tfm_ps_secure_api.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/internal_trusted_storage/tfm_its_secure_api.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/platform/tfm_platform_secure_api.o [ 37%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/spm/cmsis_psa/psa_interface_cross.o [ 37%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_psa_call_pack.o [ 37%] Linking C static library libtfm_sprt.a [ 37%] Built target tfm_sprt Scanning dependencies of target tfm_spm [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/tfm_boot_data.o [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/tfm_core_utils.o [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/utilities.o [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/arch/tfm_arch.o [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/main.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/spm_ipc.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/spm_cross_call.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/static_load.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/psa_api.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/backend_ipc.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/interrupt.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/tfm_core_svcalls_ipc.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/tfm_pools.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/thread.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ns_client_ext/tfm_spm_ns_ctx.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/arch/tfm_arch_v8m_main.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/ns_agent_tz/ns_agent_tz.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/idle_partition/idle_partition.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/psa_interface_cross.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/interface/src/tfm_psa_call_pack.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 41%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 41%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 41%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/ns_agent_tz/load_info_ns_agent_tz.o [ 41%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/idle_partition/load_info_idle_sp.o [ 41%] Linking C static library libtfm_spm.a [ 41%] Built target tfm_spm Scanning dependencies of target tfm_s [ 41%] Building C object secure_fw/CMakeFiles/tfm_s.dir/partitions/ns_agent_tz/tfm_psa_api_veneers.o [ 42%] Building ASM object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/arm/mps2/an521/gcc/startup_cmsdk_mps2_an521_s.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 43%] Building C object secure_fw/CMakeFiles/tfm_s.dir/partitions/ns_agent_tz/load_info_ns_agent_tz.o [ 43%] Building C object secure_fw/CMakeFiles/tfm_s.dir/partitions/idle_partition/load_info_idle_sp.o [ 43%] Building C object secure_fw/CMakeFiles/tfm_s.dir/spm/cmsis_psa/psa_interface_cross.o [ 43%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/interface/src/tfm_psa_call_pack.o [ 43%] Linking C executable ../bin/tfm_s.axf Memory region Used Size Region Size %age Used FLASH: 140584 B 446 KB 30.78% RAM: 73792 B 1 MB 7.04% [ 43%] Built target tfm_s Scanning dependencies of target tfm_s_hex [ 43%] Generating ../bin/tfm_s.hex [ 43%] Built target tfm_s_hex Scanning dependencies of target tfm_s_bin [ 43%] Generating ../bin/tfm_s.bin [ 43%] Built target tfm_s_bin Scanning dependencies of target tfm_s_elf [ 44%] Generating ../bin/tfm_s.elf [ 44%] Built target tfm_s_elf Scanning dependencies of target tfm_s_binaries [ 44%] Built target tfm_s_binaries [ 44%] Generating s_veneers.o Scanning dependencies of target tfm_s_veneers [ 44%] Generating s_veneers.o [ 45%] Linking C static library libtfm_s_veneers.a [ 45%] Built target tfm_s_veneers Scanning dependencies of target tfm_ns_scatter [ 45%] Building C object platform/target/CMakeFiles/tfm_ns_scatter.dir/gcc/mps2_an521_ns.ld [ 45%] Built target tfm_ns_scatter Scanning dependencies of target platform_ns [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/native_drivers/arm_uart_drv.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/native_drivers/timer_cmsdk/timer_cmsdk.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_USART.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/retarget/platform_retarget_dev.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/cmsis_core/system_cmsdk_mps2_an521.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/plat_test.o [ 47%] Building C object platform/CMakeFiles/platform_ns.dir/ext/common/uart_stdout.o [ 47%] Linking C static library libplatform_ns.a [ 47%] Built target platform_ns Scanning dependencies of target tfm_api_ns [ 47%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_platform_ipc_api.o [ 47%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_ps_ipc_api.o [ 47%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_its_ipc_api.o [ 48%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_crypto_ipc_api.o [ 48%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_initial_attestation_ipc_api.o [ 48%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_psa_ns_api.o [ 48%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/tfm_ns_interface.o [ 48%] Linking C static library libtfm_api_ns.a [ 48%] Built target tfm_api_ns Scanning dependencies of target psa_generate_database_prerequisite [ 48%] Built target psa_generate_database_prerequisite Scanning dependencies of target psa_generate_database [ 48%] Creating directories for 'psa_generate_database' [ 48%] No download step for 'psa_generate_database' [ 48%] No update step for 'psa_generate_database' [ 48%] No patch step for 'psa_generate_database' [ 50%] Performing configure step for 'psa_generate_database' -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/src/psa_generate_database-build [ 50%] No build step for 'psa_generate_database' [ 50%] Performing install step for 'psa_generate_database' [ 20%] [PSA] : Creating generator source /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/targetConfigGen.c Scanning dependencies of target TargetConfigGen [ 40%] Building C object CMakeFiles/TargetConfigGen.dir/home/a/workspace1/TF-M/trustedfirmware-m/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/trustedfirmware-m/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/trustedfirmware-m/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:1862: 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 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 吴偏偏 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

3 years, 4 months

2
1
0 0

gcc build error with TF-M v1.6.0 and v1.7.0

by Edward Yang

Hi experts, Recently we're testing TF-M v1.6.0, but a build error was encountered as shown below in red box. The build tool we used is gcc-arm-none-eabi-9-2020-q2-update, Cmake 3.19.6, the command lines are as following, mkdir cmake_build cd cmake_build cmake .. -DTFM_PLATFORM=arm/mps2/an521 -DTEST_PSA_API=CRYPTO and the detailed build log is shown below: (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m# mkdir cmake_build (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m# cd cmake_build (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build# cmake .. -DTFM_PLATFORM=arm/mps2/an521 -DTEST_PSA_API=CRYPTO -- Populating tfm_test_repo -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/lib/ext/tfm_test_repo-subbuild Scanning dependencies of target tfm_test_repo-populate [ 11%] Creating directories for 'tfm_test_repo-populate' [ 22%] Performing download step (git clone) for 'tfm_test_repo-populate' Cloning into 'tfm_test_repo-src'... remote: Enumerating objects: 2125, done. remote: Counting objects: 100% (2125/2125), done. remote: Compressing objects: 100% (1167/1167), done. remote: Total 3915 (delta 1881), reused 959 (delta 958), pack-reused 1790 Receiving objects: 100% (3915/3915), 2.34 MiB | 1.35 MiB/s, done. Resolving deltas: 100% (2747/2747), done. Checking connectivity... done. Note: checking out '723905d'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at 723905d... Test: Fix bug in BL1 TRNG testsuite [ 33%] Performing update step for 'tfm_test_repo-populate' [ 44%] No patch step for 'tfm_test_repo-populate' [ 55%] No configure step for 'tfm_test_repo-populate' [ 66%] No build step for 'tfm_test_repo-populate' [ 77%] No install step for 'tfm_test_repo-populate' [ 88%] No test step for 'tfm_test_repo-populate' [100%] Completed 'tfm_test_repo-populate' [100%] Built target tfm_test_repo-populate -- The C compiler identification is GNU 9.3.1 -- The ASM compiler identification is GNU -- Found assembler: /home/a/Tools/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc -- Found Git: /usr/bin/git (found version "2.7.4") -- Populating mbedcrypto -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/lib/ext/mbedcrypto-subbuild Scanning dependencies of target mbedcrypto-populate [ 11%] Creating directories for 'mbedcrypto-populate' [ 22%] Performing download step (git clone) for 'mbedcrypto-populate' Cloning into 'mbedcrypto-src'... remote: Enumerating objects: 24752, done. remote: Counting objects: 100% (24752/24752), done. remote: Compressing objects: 100% (12192/12192), done. remote: Total 24752 (delta 19476), reused 16609 (delta 12385), pack-reused 0 Receiving objects: 100% (24752/24752), 27.22 MiB | 193.00 KiB/s, done. Resolving deltas: 100% (19476/19476), done. Checking connectivity... done. Note: checking out 'mbedtls-3.1.0'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at d65aeb3... Merge pull request #871 from ronald-cron-arm/mbedtls-3.1.0rc0-pr [ 33%] Performing update step for 'mbedcrypto-populate' [ 44%] Performing patch step for 'mbedcrypto-populate' [ 55%] No configure step for 'mbedcrypto-populate' [ 66%] No build step for 'mbedcrypto-populate' [ 77%] No install step for 'mbedcrypto-populate' [ 88%] No test step for 'mbedcrypto-populate' [100%] Completed 'mbedcrypto-populate' [100%] Built target mbedcrypto-populate -- Populating mcuboot -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/lib/ext/mcuboot-subbuild Scanning dependencies of target mcuboot-populate [ 11%] Creating directories for 'mcuboot-populate' [ 22%] Performing download step (git clone) for 'mcuboot-populate' Cloning into 'mcuboot-src'... remote: Enumerating objects: 15238, done. remote: Counting objects: 100% (97/97), done. remote: Compressing objects: 100% (72/72), done. remote: Total 15238 (delta 25), reused 56 (delta 20), pack-reused 15141 Receiving objects: 100% (15238/15238), 5.39 MiB | 2.06 MiB/s, done. Resolving deltas: 100% (9918/9918), done. Checking connectivity... done. Note: checking out 'v1.9.0'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at c657cbe... Update to version 1.9.0 [ 33%] Performing update step for 'mcuboot-populate' [ 44%] No patch step for 'mcuboot-populate' [ 55%] No configure step for 'mcuboot-populate' [ 66%] No build step for 'mcuboot-populate' [ 77%] No install step for 'mcuboot-populate' [ 88%] No test step for 'mcuboot-populate' [100%] Completed 'mcuboot-populate' [100%] Built target mcuboot-populate -- Populating psa_arch_tests -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/lib/ext/psa_arch_tests-subbuild Scanning dependencies of target psa_arch_tests-populate [ 11%] Creating directories for 'psa_arch_tests-populate' [ 22%] Performing download step (git clone) for 'psa_arch_tests-populate' Cloning into 'psa_arch_tests-src'... remote: Enumerating objects: 12584, done. remote: Counting objects: 100% (497/497), done. remote: Compressing objects: 100% (219/219), done. remote: Total 12584 (delta 321), reused 353 (delta 277), pack-reused 12087 Receiving objects: 100% (12584/12584), 17.82 MiB | 2.50 MiB/s, done. Resolving deltas: 100% (9416/9416), done. Checking connectivity... done. Note: checking out 'f7e8495'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at f7e8495... Merge pull request #317 from joerchan/tfm-fix-wdt-timeout [ 33%] Performing update step for 'psa_arch_tests-populate' [ 44%] Performing patch step for 'psa_arch_tests-populate' [ 55%] No configure step for 'psa_arch_tests-populate' [ 66%] No build step for 'psa_arch_tests-populate' [ 77%] No install step for 'psa_arch_tests-populate' [ 88%] No test step for 'psa_arch_tests-populate' [100%] Completed 'psa_arch_tests-populate' [100%] Built target psa_arch_tests-populate -- Found Python3: /home/a/python3.6/bin/python3.6 (found version "3.6.12") found components: Interpreter Start to generate partition files: Generating Protected Storage Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/protected_storage Generating TF-M Internal Trusted Storage Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/internal_trusted_storage Generating TFM Crypto Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/crypto Generating TFM Platform Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/platform Generating TFM Initial Attestation Service in /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/generated/secure_fw/partitions/initial_attestation Per-partition files done: -- ---------- Display crypto configuration - start -------------- -- CRYPTO_RNG_MODULE_DISABLED is set to FALSE -- CRYPTO_KEY_MODULE_DISABLED is set to FALSE -- CRYPTO_AEAD_MODULE_DISABLED is set to FALSE -- CRYPTO_MAC_MODULE_DISABLED is set to FALSE -- CRYPTO_CIPHER_MODULE_DISABLED is set to FALSE -- CRYPTO_HASH_MODULE_DISABLED is set to FALSE -- CRYPTO_KEY_DERIVATION_MODULE_DISABLED is set to FALSE -- CRYPTO_ASYM_SIGN_MODULE_DISABLED is set to FALSE -- CRYPTO_ASYM_ENCRYPT_MODULE_DISABLED is set to FALSE -- CRYPTO_ENGINE_BUF_SIZE is set to 0x5000 -- CRYPTO_CONC_OPER_NUM is set to 8 -- CRYPTO_IOVEC_BUFFER_SIZE is set to 5120 -- ---------- Display crypto configuration - stop --------------- -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS - Failed -- Found Perl: /usr/bin/perl (found version "5.22.1") -- ----------- Display storage configuration - start ------------ -- PS_CREATE_FLASH_LAYOUT is set to ON -- PS_ENCRYPTION is set to ON -- PS_RAM_FS is set to OFF -- PS_ROLLBACK_PROTECTION is set to ON -- PS_VALIDATE_METADATA_FROM_FLASH is set to ON -- PS_MAX_ASSET_SIZE is set to 2048 -- PS_NUM_ASSETS is set to 10 -- PS_CRYPTO_AEAD_ALG is set to PSA_ALG_GCM -- ITS_CREATE_FLASH_LAYOUT is set to ON -- ITS_RAM_FS is set to OFF -- ITS_VALIDATE_METADATA_FROM_FLASH is set to ON -- ITS_MAX_ASSET_SIZE is set to 1229 -- ITS_NUM_ASSETS is set to 10 -- ITS_BUF_SIZE is not set (defaults to ITS_MAX_ASSET_SIZE) -- ----------- Display storage configuration - stop ------------- -- Found PythonInterp: /home/a/python3.6/bin/python3 (found suitable version "3.6.12", minimum required is "3") -- [PSA] : ----------Process input arguments- start------------- -- [PSA] : TARGET is set to tgt_dev_apis_tfm_an521 -- [PSA] : SUITE is set to CRYPTO -- [PSA] : TOOLCHAIN is set to GNUARM -- [PSA] : CPU_ARCH is set to armv8m_ml -- [PSA] : Defaulting VERBOSE to 3 -- [PSA] : Defaulting INCLUDE_PANIC_TESTS to 0 -- [PSA] : Defaulting WATCHDOG_AVAILABLE to 1 -- [PSA] : Default spec version -- [PSA] : Defaulting TESTS_COVERAGE to ALL -- [PSA] : ----------Process input arguments- complete------------- -- [PSA] : Creating testlist.txt 'available at /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/crypto_testlist.txt' Non-secure test entry symbol list: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/test_entry_list.inc, /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/test_entry_fn_declare_list.inc -- [PSA] : C compiler used '/home/a/Tools/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc' -- [PSA] : ASM compiler used '/home/a/Tools/gcc-arm-none-eabi-9-2020-q2-update/bin/arm-none-eabi-gcc' -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build (python3.6) root@Thinos16-dev:~/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build# make install Scanning dependencies of target tfm_fih_implementation [ 0%] Building C object lib/fih/CMakeFiles/tfm_fih_implementation.dir/src/fih.o [ 1%] Linking C static library libtfm_fih_implementation.a [ 1%] Built target tfm_fih_implementation Scanning dependencies of target tfm_generated_files [ 1%] Built target tfm_generated_files Scanning dependencies of target tfm_s_scatter [ 1%] Building C object platform/target/CMakeFiles/tfm_s_scatter.dir/__/__/__/__/common/gcc/tfm_common_s.ld [ 1%] Built target tfm_s_scatter Scanning dependencies of target tfm_qcbor_s [ 2%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/ieee754.o [ 2%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/qcbor_encode.o [ 2%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/qcbor_decode.o [ 2%] Building C object lib/ext/qcbor/CMakeFiles/tfm_qcbor_s.dir/src/UsefulBuf.o [ 2%] Linking C static library libtfm_qcbor_s.a [ 2%] Built target tfm_qcbor_s Scanning dependencies of target tfm_t_cose_s [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_sign1_sign.o [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_sign1_verify.o [ 2%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_util.o [ 3%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/src/t_cose_parameters.o [ 3%] Building C object lib/ext/t_cose/CMakeFiles/tfm_t_cose_s.dir/crypto_adapters/t_cose_psa_crypto.o [ 3%] Linking C static library libtfm_t_cose_s.a [ 3%] Built target tfm_t_cose_s Scanning dependencies of target platform_s [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_Flash.o [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_MPC.o [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_PPC.o [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_USART.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/retarget/platform_retarget_dev.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/cmsis_core/system_cmsdk_mps2_an521.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/mpc_sie200_drv.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/mpu_armv8m_drv.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/ppc_sse200_drv.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/spm_hal.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/tfm_interrupts.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/tfm_hal_isolation.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/tfm_hal_platform.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/target_cfg.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/arm_uart_drv.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/native_drivers/timer_cmsdk/timer_cmsdk.o [ 5%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_nvic.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_isolation_mpu_v8m.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/target/arm/mps2/an521/services/src/tfm_platform_system.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_ps.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_its.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_platform.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/uart_stdout.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/faults.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/tfm_hal_memory_symbols.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/attest_hal.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/nv_counters.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/crypto_keys.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/tfm_rotpk.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/crypto_nv_seed.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/flash_otp_nv_counters_backend.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/otp_flash.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/provisioning.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/__/secure_fw/spm/cmsis_psa/psa_interface_cross.o [ 8%] Building C object platform/CMakeFiles/platform_s.dir/__/interface/src/tfm_psa_call_pack.o [ 9%] Linking C static library libplatform_s.a [ 9%] Built target platform_s Scanning dependencies of target tfm_psa_rot_partition_platform [ 9%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/platform_sp.o [ 9%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/generated/secure_fw/partitions/platform/auto_generated/intermedia_tfm_platform.o [ 9%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 9%] Building C object secure_fw/partitions/platform/CMakeFiles/tfm_psa_rot_partition_platform.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 9%] Linking C static library libtfm_psa_rot_partition_platform.a [ 9%] Built target tfm_psa_rot_partition_platform Scanning dependencies of target tfm_psa_rot_partition_its [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/tfm_its_req_mngr.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/tfm_internal_trusted_storage.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/its_utils.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash_nand.o [ 10%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash_nor.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash/its_flash_ram.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash_fs/its_flash_fs.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash_fs/its_flash_fs_dblock.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/flash_fs/its_flash_fs_mblock.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/intermedia_tfm_internal_trusted_storage.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 11%] Building C object secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 12%] Linking C static library libtfm_psa_rot_partition_its.a [ 12%] Built target tfm_psa_rot_partition_its Scanning dependencies of target tfm_app_rot_partition_ps [ 12%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/tfm_ps_req_mngr.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/tfm_protected_storage.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_object_system.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_object_table.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_utils.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/crypto/ps_crypto_interface.o [ 13%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/ps_encrypted_object.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/nv_counters/ps_nv_counters.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/intermedia_tfm_protected_storage.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 14%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/__/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/ns_agent_tz/load_info_ns_agent_tz.o [ 15%] Building C object secure_fw/partitions/protected_storage/CMakeFiles/tfm_app_rot_partition_ps.dir/__/idle_partition/load_info_idle_sp.o [ 15%] Linking C static library libtfm_app_rot_partition_ps.a [ 15%] Built target tfm_app_rot_partition_ps Scanning dependencies of target tfm_psa_rot_partition_attestation [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest.o [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/tfm_attest_req_mngr.o [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_core.o [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_asymmetric_key.o [ 15%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/attest_token_encode.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/intermedia_tfm_initial_attestation.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_sign.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_sign1_verify.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_util.o [ 17%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/src/t_cose_parameters.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 18%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/__/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 19%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/ns_agent_tz/load_info_ns_agent_tz.o [ 19%] Building C object secure_fw/partitions/initial_attestation/CMakeFiles/tfm_psa_rot_partition_attestation.dir/__/idle_partition/load_info_idle_sp.o [ 19%] Linking C static library libtfm_psa_rot_partition_attestation.a [ 19%] Built target tfm_psa_rot_partition_attestation [ 19%] Generating version_features.c [ 19%] Generating error.c [ 19%] Generating ssl_debug_helpers_generated.h, ssl_debug_helpers_generated.c Scanning dependencies of target crypto_service_mbedcrypto [ 19%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/aes.o [ 19%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/aesni.o [ 19%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/aria.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/asn1parse.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/asn1write.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/base64.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/bignum.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/camellia.o [ 20%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ccm.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/chacha20.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/chachapoly.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/cipher.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/cipher_wrap.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/constant_time.o [ 21%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/cmac.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ctr_drbg.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/des.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/dhm.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecdh.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecdsa.o [ 22%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecjpake.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecp.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ecp_curves.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/entropy.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/entropy_poll.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/error.o [ 23%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/gcm.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/hkdf.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/hmac_drbg.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/md.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/md5.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/memory_buffer_alloc.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/mps_reader.o [ 24%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/mps_trace.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/nist_kw.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/oid.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/padlock.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pem.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pk.o [ 25%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pk_wrap.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkcs12.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkcs5.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkparse.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/pkwrite.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/platform.o [ 26%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/platform_util.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/poly1305.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_aead.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_cipher.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_client.o [ 27%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_driver_wrappers.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_ecp.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_hash.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_mac.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_rsa.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_se.o [ 28%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_slot_management.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_crypto_storage.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/psa_its_file.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ripemd160.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/rsa.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/rsa_alt_helpers.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/sha1.o [ 29%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/sha256.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/sha512.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/ssl_debug_helpers_generated.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/threading.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/timing.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/version.o [ 30%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/version_features.o [ 31%] Building C object secure_fw/partitions/crypto/mbedcrypto/library/CMakeFiles/crypto_service_mbedcrypto.dir/__/__/__/__/__/secure_fw/partitions/crypto/tfm_mbedcrypto_alt.o [ 31%] Linking C static library libmbedcrypto.a [ 31%] Built target crypto_service_mbedcrypto Scanning dependencies of target tfm_psa_rot_partition_crypto [ 31%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_init.o [ 31%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_alloc.o [ 31%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_cipher.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_hash.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_mac.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_key.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_aead.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_asymmetric.o [ 32%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_key_derivation.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_key_management.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/crypto_rng.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/generated/secure_fw/partitions/crypto/auto_generated/intermedia_tfm_crypto.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/spm/cmsis_psa/psa_interface_cross.o [ 34%] Building C object secure_fw/partitions/crypto/CMakeFiles/tfm_psa_rot_partition_crypto.dir/__/__/__/interface/src/tfm_psa_call_pack.o [ 34%] Linking C static library libtfm_psa_rot_partition_crypto.a [ 34%] Built target tfm_psa_rot_partition_crypto Scanning dependencies of target tfm_sprt [ 34%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memcmp.o [ 34%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memcpy.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memmove.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_memset.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/crt_strnlen.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/service_api.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/sprt_partition_metadata_indicator.o [ 35%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/sprt_main.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/sfn_common_thread.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/crypto/tfm_crypto_secure_api.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/initial_attestation/tfm_attest_secure_api.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/protected_storage/tfm_ps_secure_api.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/internal_trusted_storage/tfm_its_secure_api.o [ 36%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/platform/tfm_platform_secure_api.o [ 37%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/spm/cmsis_psa/psa_interface_cross.o [ 37%] Building C object secure_fw/partitions/lib/sprt/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_psa_call_pack.o [ 37%] Linking C static library libtfm_sprt.a [ 37%] Built target tfm_sprt Scanning dependencies of target tfm_spm [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/tfm_boot_data.o [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/tfm_core_utils.o [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/utilities.o [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/arch/tfm_arch.o [ 37%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/main.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/spm_ipc.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/spm_cross_call.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/static_load.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/psa_api.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/backend_ipc.o [ 38%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ffm/interrupt.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/tfm_core_svcalls_ipc.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/tfm_pools.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/thread.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ns_client_ext/tfm_spm_ns_ctx.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/arch/tfm_arch_v8m_main.o [ 39%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/ns_agent_tz/ns_agent_tz.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/idle_partition/idle_partition.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/cmsis_psa/psa_interface_cross.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/interface/src/tfm_psa_call_pack.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 40%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 41%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 41%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 41%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/ns_agent_tz/load_info_ns_agent_tz.o [ 41%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/partitions/idle_partition/load_info_idle_sp.o [ 41%] Linking C static library libtfm_spm.a [ 41%] Built target tfm_spm Scanning dependencies of target tfm_s [ 41%] Building C object secure_fw/CMakeFiles/tfm_s.dir/partitions/ns_agent_tz/tfm_psa_api_veneers.o [ 42%] Building ASM object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/arm/mps2/an521/gcc/startup_cmsdk_mps2_an521_s.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/crypto/auto_generated/load_info_tfm_crypto.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/initial_attestation/auto_generated/load_info_tfm_initial_attestation.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/internal_trusted_storage/auto_generated/load_info_tfm_internal_trusted_storage.o [ 42%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/generated/secure_fw/partitions/platform/auto_generated/load_info_tfm_platform.o [ 43%] Building C object secure_fw/CMakeFiles/tfm_s.dir/partitions/ns_agent_tz/load_info_ns_agent_tz.o [ 43%] Building C object secure_fw/CMakeFiles/tfm_s.dir/partitions/idle_partition/load_info_idle_sp.o [ 43%] Building C object secure_fw/CMakeFiles/tfm_s.dir/spm/cmsis_psa/psa_interface_cross.o [ 43%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/interface/src/tfm_psa_call_pack.o [ 43%] Linking C executable ../bin/tfm_s.axf Memory region Used Size Region Size %age Used FLASH: 140584 B 446 KB 30.78% RAM: 73792 B 1 MB 7.04% [ 43%] Built target tfm_s Scanning dependencies of target tfm_s_hex [ 43%] Generating ../bin/tfm_s.hex [ 43%] Built target tfm_s_hex Scanning dependencies of target tfm_s_bin [ 43%] Generating ../bin/tfm_s.bin [ 43%] Built target tfm_s_bin Scanning dependencies of target tfm_s_elf [ 44%] Generating ../bin/tfm_s.elf [ 44%] Built target tfm_s_elf Scanning dependencies of target tfm_s_binaries [ 44%] Built target tfm_s_binaries [ 44%] Generating s_veneers.o Scanning dependencies of target tfm_s_veneers [ 44%] Generating s_veneers.o [ 45%] Linking C static library libtfm_s_veneers.a [ 45%] Built target tfm_s_veneers Scanning dependencies of target tfm_ns_scatter [ 45%] Building C object platform/target/CMakeFiles/tfm_ns_scatter.dir/gcc/mps2_an521_ns.ld [ 45%] Built target tfm_ns_scatter Scanning dependencies of target platform_ns [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/native_drivers/arm_uart_drv.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/native_drivers/timer_cmsdk/timer_cmsdk.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/cmsis_drivers/Driver_USART.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/retarget/platform_retarget_dev.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/cmsis_core/system_cmsdk_mps2_an521.o [ 46%] Building C object platform/CMakeFiles/platform_ns.dir/ext/target/arm/mps2/an521/plat_test.o [ 47%] Building C object platform/CMakeFiles/platform_ns.dir/ext/common/uart_stdout.o [ 47%] Linking C static library libplatform_ns.a [ 47%] Built target platform_ns Scanning dependencies of target tfm_api_ns [ 47%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_platform_ipc_api.o [ 47%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_ps_ipc_api.o [ 47%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_its_ipc_api.o [ 48%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_crypto_ipc_api.o [ 48%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_initial_attestation_ipc_api.o [ 48%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/__/__/__/interface/src/tfm_psa_ns_api.o [ 48%] Building C object tf-m-tests/app/CMakeFiles/tfm_api_ns.dir/tfm_ns_interface.o [ 48%] Linking C static library libtfm_api_ns.a [ 48%] Built target tfm_api_ns Scanning dependencies of target psa_generate_database_prerequisite [ 48%] Built target psa_generate_database_prerequisite Scanning dependencies of target psa_generate_database [ 48%] Creating directories for 'psa_generate_database' [ 48%] No download step for 'psa_generate_database' [ 48%] No update step for 'psa_generate_database' [ 48%] No patch step for 'psa_generate_database' [ 50%] Performing configure step for 'psa_generate_database' -- Configuring done -- Generating done -- Build files have been written to: /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/src/psa_generate_database-build [ 50%] No build step for 'psa_generate_database' [ 50%] Performing install step for 'psa_generate_database' [ 20%] [PSA] : Creating generator source /home/a/workspace1/TF-M/trustedfirmware-m/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/targetConfigGen.c Scanning dependencies of target TargetConfigGen [ 40%] Building C object CMakeFiles/TargetConfigGen.dir/home/a/workspace1/TF-M/trustedfirmware-m/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/trustedfirmware-m/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/trustedfirmware-m/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:1862: 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 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 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd

3 years, 4 months

2
1
0 0

RSS target platform

by Peter Sawicki

Hi, I wonder which target platform is used to run RSS. According to the https://tf-m-user-guide.trustedfirmware.org/platform/arm/rss/readme.html it's a Total Compute platform. But there are two FVPs i.e. TC1 and TC2, both available on https://developer.arm.com/downloads/-/arm-ecosystem-fvps. They are equipped only with SCP. I suppose that this is TC2, which is currently not publicly available ("HW Root of Trust based on the TF-M RSS subsystem." a cite from https://arm-reference-solutions-docs.readthedocs.io/en/tc2-2022.12.07/docs/…) Is the TC2 the only target that is currently used for RSS development? Kind regards, Peter

3 years, 4 months

2
6
0 0

Region Limits

by Chris.Brand＠infineon.com

Hi, Looking at platform/ext/common/tfm_hal_platform_v8m.c, this line stands out as quite odd: .veneer_limit = (uint32_t)&REGION_NAME(Image$$, VENEER_ALIGN, $$Limit) - 1, It seems that the various "$$Limit" values that exist within TF-M aren't actually "limits" in the usual meaning of the word (the last value within the range) but are instead the first value *outside* the range. Elsewhere in TF-M we do seem to use the word "limit" in the conventional way. I worry that this could lead to errors around the boundaries, particularly as some functions we use to check ranges take a "limit" parameter - we could easily see code that looks correct but that actual does the wrong thing, like ARM_MPC_ConfigRegion(REGION_NAME(Image$$, ER_VENEER, $$Base), REGION_NAME(Image$$, VENEER_ALIGN, $$Limit, attr); Or a similar call to check_address_range(). For example, I suspect that this is a bug in the Nuvoton M2354 platform caused by this issue: platform/ext/target/nuvoton/m2354/target_cfg.c: .veneer_limit = (uint32_t)&REGION_NAME(Image$$, VENEER_ALIGN, $$Limit), It's obviously a big thing to fix, but it does look to me to be worthwhile... Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> 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.

3 years, 4 months

3
4
0 0

Disable FLIH tests in CI

by Xinyu Zhang

Hi All, it is spotted that FLIH tests failed recently and blocks CI verification. We need to dig into it and found the reason. To avoid blocking the daily work, we will temporarily turn FLIH tests off, and recover when solved. Background: Sometimes the test application stuck in waiting for interrupts even the interrupt is properly configured. If someone got solutions for similar problems please share your info, thank you in advance. Best Regards, Xinyu

3 years, 4 months

1
0
0 0

MbedCrypto linking problem in isolation L3

by Bohdan.Hunko＠infineon.com

Hi all, After having some troubles with isolation level 3 I have noticed that MbedTLS (mbedcrypto) data/code is not properly linked to crypto partition. Currently mbed crypto data/code is placed into SPM data/code section in level 3 isolation. This is a problem if optional L3 FFM boundaries are applied (when SPM is isolated from PSA RoT partition (Crypto in particular)) because in this case crypto partition does not have access to the mbedcrypto code/data that is located in SPM code/data sections. I think Mbedcrypto data/code should be linked to crypto partition and placed in crypto partition linker section. This way it will be protected to be accessible by crypto partition. So my question is whether this should be fixed or there are objectives to not fix this issue? If fix is needed I would like to discuss possible ways to solve this problem. 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>

3 years, 4 months

2
6
0 0

TF-M Open CI is blocked

by Anton Komlev

TF-M Open CI is blocked. Please avoid starting new jobs as it would not start and can be cancelled for restart. We'll let you know once it is back to normal. Sorry for this news, Anton

3 years, 4 months

1
1
0 0

Branch release/1.6.x to be deleted

by Anton Komlev

Hi, Please be aware that the branch release/1.6.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=release/…> is to be removed, following TF-M release process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Please stop using it by the end of this week (Jan 13) or let me know if more time is necessary. The previous releases will be still available via tags like TF-Mv1.6.1<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.6…> Thanks, Anton

3 years, 5 months

1
0
0 0

minor bug in an521 protections

by Bohdan.Hunko＠infineon.com

Hi, I have been working on TZ stuff recently and found small problem in an521 platform protections. The problem is in SAU config. sau_cfg in platform/ext/target/arm/mps2/an521/target_cfg.c has entry for NSPE code: { ((uint32_t)NS_PARTITION_START), ((uint32_t)NS_PARTITION_START + NS_PARTITION_SIZE - 1), false, }, Where both NS_PARTITION_START and NS_PARTITION_SIZE are 32 bytes aligned, which means that when 1 is subtracted lower 5 bits are getting set to 1, for example: 0x1000_0000 + 0x1000 - 1 = 0x10000FFF Then in sau_and_idau_cfg() function lower 5 bits are cleared by the mask: sau_cfg[i].RLAR & SAU_RLAR_LADDR_Msk This means that in reality highest 32 bytes of NSPE are protected as Secure in SAU. Same problem is present for SECONDARY_PARTITION_SIZE SAU entry. This is not huge problem, but still worth fixing. I believe other arm and TZ platforms may also have this bug, but I haven't checked in details. 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>

3 years, 5 months

3
6
0 0

SAU region setting check request

by Ken Liu

Hi, It is reported in a few platforms that the SAU NSC region limit is set 32 bytes larger than expected because the value set did not match the hardware characteristics. The SAU.LADDR treats the last 5 bits as 0x1 which means a valid limit address should be the value with 0x1f in the last bits, take an example if the region starts at 0x1000 with size 0x100, the limit address should be set as 0x1000 + 0x100 - 0x20 which is 0x10E0. The practical region address range is [0x1000 - 0x10FF], all addresses >= 0x1000 and <= 0x10FF would be treated as hitting a region. If your address and size are 32 bytes aligned already, you can just adjust the limit with "start_address + size - 1", as the tailing 5 bits would be masked. Take this patch as an example: Platform: Fix the Veneer SAU region for Arm platforms (I2692f318) · Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/18547> Now only the NSC region is affected, but please check your platform if you are using SAU to see if each region is set properly. Thanks. /Ken

3 years, 5 months

1
0
0 0

TF-M Open CI Down

by Xinyu Zhang

Hi, Sorry to inform you that TF-M Open CI is down. We are trying hard to fix. We'll let you know once it is back to normal. Best Regards, Xinyu

3 years, 5 months

1
1
0 0

Multi slot queue in bare metal NSPE

by Bohdan.Hunko＠infineon.com

Hi all, TFM in current implementation has following condition in tfm_ns_mailbox.h #if !defined(TFM_MULTI_CORE_NS_OS) && (NUM_MAILBOX_QUEUE_SLOT > 1) #error "NUM_MAILBOX_QUEUE_SLOT should be set to 1 for NS bare metal environment" #endif I was wondering whether this is real restriction or this check can be removed. I am not mailbox expert so please correct me if I am wrong. Quick look at the code shows that it should be ok to have multi slot queue in bare metal environment, with the note that only one slot will be used (as there is only one thread). If my understanding is correct then it would be nice to remove this compile time check (I am happy to provide a patch for it). We need this change because we deliver TFM as prebuilt binary and interface (one installed after the build). This binary is built with NUM_MAILBOX_QUEUE_SLOT = 4, so in current implementation it cant be used in bare metal environment. 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>

3 years, 5 months

2
1
0 0

FW: [Maintenance] - ci.trustedfirmware.org down time 2022-12-16

by Xinyu Zhang

Hi, FYI. TF-M Open CI will be on maintenance on 16th Dec. Time to stop triggering new jobs: 2022-12-16 18:00 UTC Maintenance end time: 2022-12-16 22:00 UTC Regards, Xinyu From: Kelley Spoon via Tf-openci-triage <tf-openci-triage(a)lists.trustedfirmware.org> Sent: Thursday, December 15, 2022 4:16 AM To: tf-openci(a)lists.trustedfirmware.org; tf-openci-triage(a)lists.trustedfirmware.org Subject: [Tf-openci-triage] [Maintenance] - ci.trustedfirmware.org down time 2022-12-16 Hello All, The server will be offline to start a maintenance window on 2022-12-16 at 20:00 UTC. Jenkins will be put into "Shutdown Mode" at 2022-12-16 18:00 UTC to stop accepting new jobs and allow executing tasks to complete. This downtime is required to execute an upgrade for Jenkins to address some security advisories and enable new functionality. Emails will be sent prior to and following the upgrade to provide status reports. Start: 2022 12-16 20:00 UTC End: 2022-12-16 22:00 UTC Regards, -- Kelley Spoon <kelley.spoon(a)linaro.org<mailto:kelley.spoon@linaro.org>>

3 years, 5 months

1
0
0 0

TF-M Open CI is Down

by Xinyu Zhang

Hi, Sorry to inform you that TF-M Open CI is currently down for the time being. We'll let you know once it is back to normal. Best Regards, Xinyu

3 years, 6 months

1
1
0 0

TF-M release v1.7.0 announcement

by Anton Komlev

Hello, I am pleased to announce the release of TF-M v1.7.0. New major features are: * Unified API to PSA Service access implementing PSA FF-M and FF-M v1.1 extension * The Library model is deprecated and removed * Improve and simplify TF-M configurability * Introduce the base configuration for TF-M essential * Shift config options from CMake to C header files for PSA modules and platforms * Employ Kconfig as a configuration tool and dependency tracker * Configurable stack size for Secure Partitions * Add TF-M Medium-ARoT-less profile * MM-IOVEC deployed in PSA Secure Partitions * PSA FWU API updated to v1.0 * Mbed TLS updated to v3.2.1 * Code size further optimised * The manifest tool is decoupled with the build system * Improvements in the Code size analysis tool * Updated documentation It is tagged with TF-Mv1.7.0<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.7…>. The release time changes will be integrated with the main branch shortly. Many thanks everyone for contribution, review and support this milestone. Anton

3 years, 6 months

1
0
0 0

TF-M and communication stack in NSPE

by Romain JAYLES

Hello, We are currently integrating a protocol stack with a Radio IRQ in a TrustZone environment with the TF-M as the SPE. The Radio IRQ requires fast treatment from our protocol stack, the need is to have the Radio IRQ handled with the lowest latency possible. The fact that all the IRQs in the NonSecure side can't preempt IRQ on the Secure side in the TF-M design leads us to the following possibilities with several limitations: 1. Having the Radio IRQ as the lowest priority on the NonSecure side: if a user creates its own partition with an IRQ (which by design will have a lower priority of our IRQ because it's in the Secure side), it could potentially delay for too long the Radio IRQ processing, thus leading to Radio protocol related issues. 1. Having the protocol stack related to the Radio IRQ in a partition directly in Secure side : this configuration is highly disputable from a Security point of view, the possibility to introduce a Security flaw with the protocol stack in Secure being too high. 1. Having the Radio IRQ in a Secure partition (FLIH for faster handling) and forward the IRQ handling to the protocol stack in the NonSecure side, all modifications to the NVIC registers of this Radio IRQ (enable, disable, priority level) requested by the protocol stack in NonSecure side will have to be done through this partition with TF-M API calls (SFN backend for execution performances) : This configuration will probably led to issues such as reentrancy on the TF-M (for example if the TF-M forward an IRQ to the NonSecure which then calls TF-M API for Radio NVIC register manipulations) or having to call TF-M from NonSecure in handler mode. Do you already have experienced with this type of problematics, or do you see TF-M configurations which will be more suitable for such a use-case ? Thank you, Regards, Romain ST Restricted

3 years, 6 months

3
6
0 0

TF-M threat modeling diagrams

by Bohdan.Hunko＠infineon.com

Hi all, Our team is working on TFM threat modeling, we are analyzing existing code to find and fix any security issues/problems with it. To better perform this modeling we are interested in having detailed diagrams of TFM boot and execution flows. Ideally the diagrams should be quite detailed to show system state transitions, detailed execution flow and any actions that are not obvious when first looking into TFM code (e.g. scheduling of nested calls, execution of secure IRQs that interrupt nested scheduling, ....). Does TFM community have such (or similar) diagrams/? If so then where can we find them? We think that these diagrams may be very useful to TFM in general. They will let TFM users easily understand how TFM works (in details). 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>

3 years, 6 months

2
1
0 0

Start of TF-M v1.7.0 release process

by Anton Komlev

Hello, The branch release/1.7.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=release/…> has been created indicating the start of the release process and features freeze. RC1 tag will follow after successful run of the basic tests. Let me remind that the code is not frozen, and development can be continued on the main branch. Thanks, Anton

3 years, 6 months

1
3
0 0

CMake 3.25.0 build issue

by Bøe, Sebastian

Hi, when I updated from CMake 3.24.0 to the new (two weeks old) CMake 3.25.0 I am no longer able to build TF-M with -DTEST_PSA_API=CRYPTO. (Downgrading CMake fixes the issue) Is there an interoperability issue with the latest CMake release and the TF-M build system? Reproduced with TF-Mv1.7.0-RC1 TF-Mv1.6.0 Steps to reproduce: 1. install CMake 3.25.0. 1. cd trusted-firmware-m 1. rm -rf cmake_build && cmake -G Ninja -S . -B cmake_build -DTEST_PSA_API=CRYPTO -DTFM_PLATFORM=nordic_nrf/nrf5340dk_nrf5340_cpuapp -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug && ninja -C cmake_build Only reproduces with TEST_PSA_API and CMake 3.25.0. Builds fine with 3.24.0 or non-PSA API builds. error: file INSTALL cannot find "/home/sebo/ncs/modules/tee/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/src/psa_generate_database-build/target_database.h": No such file or directory.

3 years, 6 months

3
2
0 0

Trusted Firmware M build error on Windows 10

by Pocsai Ildiko LCPF-CH

Hello, I'm trying to build the Trusted Firmware M on Win10 x64 for NXP LPC55S69 using the IAR compiler, but I get the following error: [ 76%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/nxp/lpcxpresso55s69/Device/Source/startup_lpcxpresso55s69.o extern uint32_t __INITIAL_SP; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe007]: unrecognized token extern uint32_t __INITIAL_SP; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe065]: expected a ";" extern uint32_t __INITIAL_SP; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe007]: unrecognized token extern uint32_t __STACK_LIMIT; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe007]: unrecognized token extern uint32_t __STACK_LIMIT; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe065]: expected a ";" extern uint32_t __STACK_LIMIT; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe007]: unrecognized token (VECTOR_TABLE_Type)(&__INITIAL_SP), /* Initial Stack Pointer */ In the attachment, you can find the full build log and also the CMake build file generation log. Some details about my setup: Win10 Enterprise x64. Version 20H2 IAR ANSI C/C++ Compiler V8.50.9.278/W32 for ARM GNU Make 3.81 git version 2.36.0.windows.1 CMake 3.24.2 Python 3.10.5 I followed the steps from the Getting started guide here<https://tf-m-user-guide.trustedfirmware.org/getting_started/index.html> than the steps to build the framework for LPC55S69 here<https://tf-m-user-guide.trustedfirmware.org/platform/nxp/lpcxpresso55s69/RE…>. Do you have any idea what I'm missing? In case you need any further information let me please know. Thanks in advance. Kind regards, Ildikó Pocsai

3 years, 6 months

6
11
0 0

Number context for NS

by Michel JAOUEN

Hello, I see that in coming 1.7.0 the file secure_fw/spm/ns_client_ext/tfm_ns_ctx.h contains a comment /* Supported maximum context for NS. Only support single context for now. */ #define TFM_NS_CONTEXT_MAX 1 Does it mean that several simultaneous NSC call is not supported ? Best regards ST Restricted

3 years, 6 months

2
1
0 0

Interrupt SLIH Scheduling

by vivahavey＠gmail.com

Dear developers, I have a question about interrupt SLIH scheduling in IPC model. Assume that there are two secure partitions P1 and P2, and P1 has higher priority than P2. P1 calls psa_call(), so SPM blocks P1 and wakes up P2 to execute P2's service handler. Now P2 is running. Suddenly P1's interrupt occuerred, and P1's SLIH signal is asserted for more processing. A shedule request is also triggered. Since P1 has higher priority than P2, will P2 be preemted by P1 to execute P1's SLIH immediately? If the answer is yes, the psa_call() chain will be corrupted, right? Thanks in advance. Alvin Chang

3 years, 6 months

3
3
0 0

Platform/Application specific service extension

by Roman.Mazurak＠infineon.com

Hi, Partition is described through configuration in YAML files (manifests). This configuration includes following properties (see Adding Secure Partition - Add manifest<https://tf-m-user-guide.trustedfirmware.org/integration_guide/services/tfm_…>): * Name, type, priority, model, ... * List of services provided by partition * MMIO regions * List of IRQs * Dependencies Each platform should provide implementation of HAL which is specific to standard partitions like Crypto, ITS, etc. It's mandatory to provide proper isolation of memory/peripheral that are used by platform specific code that provides HAL implementation or add a custom dependency for standard partition. Currently platform can use following approaches to resolve the problem of extending YAML of standard TF-M partition: * Create a platform specific copy of partition YAML, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15639 as an example of such approach. * Modify standard partition by introducing optional fields, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/17718. These both solution are not flexible enough. It requires to modify platform independent code or maintain own copy of partition YAML file with needed changes. I think it make sense to integrate partition YAML extension tool in TF-M. Platform/application should be able to provide manifest-extension file(s). Such manifest-extension file may provide additional properties which should be joined with properties provided by standard partition manifest files. For example to solve problem for https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15639 ARM RSS platform may provide following manifest-extension file with structure like this: { "extensions": [ { "name": "TFM_SP_INITIAL_ATTESTATION", "dependencies": [ "TFM_MEASURED_BOOT" ] } ] } Tool which parses manifests should add a new dependency on "TFM_MEASURED_BOOT" to list of dependencies for "TFM_SP_INITIAL_ATTESTATION" partition. Please, share your opinion on this topic. Best regards, Roman.

3 years, 6 months

2
1
0 0

Deleting last object in a data block in ITS filesystem

by Stefan Krug

Hello! Seemingly, there is an issue with file deletion in ITS. I would think it is not possible to delete the last object in a data block (so that the data block becomes empty). It's easiest to reproduce with using large objects (because then the number of involved objects is small), but would also happen with multiple smaller objects: With the following flash configuration: ITS_MAX_ASSET_SIZE=0x1000 TFM_HAL_ITS_SECTORS_PER_BLOCK=1 TFM_HAL_ITS_FLASH_AREA_SIZE=0x20000 TFM_HAL_ITS_PROGRAM_UNIT=0x100 ITS_FLASH_NAND_BUF_SIZE=1*0x1000 In a sequence of writing and deleting an object like: const uint8_t big_file[ITS_MAX_ASSET_SIZE] = {0}; status = psa_its_set(uid, sizeof(big_file), big_file, flags); status = psa_its_remove(uid); deleting the file fails with the status of PSA_ERROR_GENERIC_ERROR. What I think happens is: Due to the size of the file, it does not fit in the metadata block, and is put a second (data only) block. The object is written there as expected. When the data block is deleted later, an attempt is being made to compact it with its_flash_fs_dblock_compact_block(). However, there is no data to keep before the object to be deleted and also no data to keep after it, this block will become empty, so no call to its_flash_fs_block_to_block_move() happens, which causes no call to fs_ctx->ops->write() happens. Now the flash driver in my case is a buffering its_flash_nand.c. In the write() call it would associate a buffer for the physical sector to write. But since there is no write() call the subsequent fs_ctx->ops->flush() fails as it has no buffer to flush out. I believe no compaction of the block should even be attempted - it is known that the block will be empty beforehand. Perhaps similar to https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/17578, this is yet another reason to skip compacting of the block? It would be very much appreciated if one of the experts could confirm this suspicious behavior or point out a mistake I am making. Thank you very much, best regards Stefan Krug

3 years, 6 months

2
1
0 0

Announcing TF-Mv1.6.1 fix

by Anton Komlev

Hello, This is an announcement of TF-M v1.6.1 hotfix preparation. The reason for the hot fix is the recently found incorrect stack sealing in Library model. The library mode is deprecated already but is available in v1.6.0 and the intention is to leave it in the best shape to our knowledge. Security analysis shows no vulnerability was brought by this defect, so it is not a security fix. The plan is to issue the fix by Nov 17. TF-M release cadence and process is here: https://tf-m-user-guide.trustedfirmware.org/releases/release_process.htmlte… Thanks, Anton

3 years, 6 months

1
1
0 0

TF-M Profile Medium-ARoT-less

by David Hu

Hi all, TF-M Profile Medium-ARoT-less is proposed to align with PSA Certified ARoT-less Level 2 protection profile [1]. May I ask for your review and comment please? Please check following patches: https://review.trustedfirmware.org/q/topic:%22arot-less%22+(status:open%20O… Any feedback is welcome. [1] https://www.psacertified.org/app/uploads/2022/10/JSADEN019-PSA_Certified_Le… Best regards, Hu Ziji

3 years, 7 months

1
0
0 0

Lost data when overwriting object using its_set?

by Stefan Krug

Hello! While playing around with TF-M I have stumbled upon unexpected behavior: In a sequence of ITS api calls like: a.) psa_its_set(TEST_UID_1, sizeof(write_data_1), write_data_1, PSA_STORAGE_FLAG_NONE); b.) psa_its_set(TEST_UID_2, 0, NULL, PSA_STORAGE_FLAG_NONE); c.) psa_its_remove(TEST_UID_1); d.) psa_its_set(TEST_UID_2, sizeof(write_data_2), write_data_2, PSA_STORAGE_FLAG_NONE); e.) psa_its_get(TEST_UID_2, 0, sizeof(read_data_2), read_data_2, &read_data_length); with #define TEST_UID_1 2U #define TEST_UID_2 3U const uint8_t write_data_1[] = "ONE"; const uint8_t write_data_2[] = "TWO"; It seems that step e) does not return the data written in step d). I believe I have root-caused it to an issue in its_flash_delete_idx() (see below), but since this is a rather straightforward API call sequence, I wonder whether this is not rather an issue in my environment and would be glad if someone could confirm it or point me to a direction of a potential different cause? I am using TF-M version 1.6, a nor flash with (erase) block size 0x1000 bytes and a program unit size (page size) of 0x100 bytes. Thank you, best regards Stefan Krug More analysis details: After step c) there will be the following relevant metadata blocks in the filesystem: 1.) unused metadata block (used to have the metadata of TEST_UID_1) 2.) metadata block of TEST_UID_2 During step d) the update of TEST_UID_2 is done in two steps - first step is to write metadata + content of TEST_UID_2. After this step, the metadata blocks look like: 1.) NEW metadata block of TEST_UID_2 2.) old metadata block of TEST_UID_2 (indicating TEST_UID_2 to be erased) The second step is to delete the outdated file, and compact/defragment the data in the file system. This is done in its_flash_fs_delete_idx(). its_flash_fs_delete_idx will collect the amount of data bytes to preserve. There are two parts of data to be preserved, a chunk of data before the deleted file (of size del_file_data_idx) and a chunk of data after the deleted file. Calculation of del_file_data_idx is done by taking the start offset of the to-be-deleted file. In this particular situation the start of the old TEST_UID_2 is the same as the start of the new TEST_UID_2. The subsequent its_flash_fs_dblock_compact_block will only keep data up to del_file_data_idx - in this case it will NOT keep the data of the new TEST_UID_2 - this data is lost.

3 years, 7 months

2
1
0 0

Latest status of S/NS build split PoC

by David Hu

Hi all, I rebase and update the S/NS build split PoC as requests. Could you please take a look at the latest patch set if you are interested? Trusted-firmware-m part: https://review.trustedfirmware.org/q/project:TF-M%252Ftrusted-firmware-m+br… Tf-m-tests part: https://review.trustedfirmware.org/q/project:TF-M%252Ftf-m-tests+branch:mas… The general idea was presented in https://www.trustedfirmware.org/docs/tf-m_forum_20220120_Restructure_TF-M_b… while some details are improved in code. Any comment and feedback is welcome! Best regards, Hu Ziji

3 years, 7 months

1
0
0 0

TFM_PARTITION_AUDIT_LOG references in the code after Lib Model deprecation

by Bohdan.Hunko＠infineon.com

Hi all, TFM Library model has been deprecated, thus AUDIT logging partition has been deleted, but I still see a reference to that partition in config/check_config.cmake lines 102-103: #Audit log is not supported in IPC model, disable it by default tfm_invalid_config(TFM_PARTITION_AUDIT_LOG) Looks like this should be removed or comment fixed. An I missing something or this is a mistake that should be fixed? 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>

3 years, 7 months

3
2
0 0

an521 L3 protection setting questions

by Bohdan.Hunko＠infineon.com

Hi all, I have a few questions regarding an521 platform protection settings for Level 3 isolation. In platform/ext/target/arm/mps2/an521/tfm_hal_isolation.c there is an const static struct mpu_armv8m_region_cfg_t region_cfg[] - for L3 it specifies to protect: * Code (from Image$$PT_RO_START$$Base to Image$$PT_RO_END$$Base) to be accessible in both PRIV and UNPRIV states. * PSA RoT partitions data in RAM (from Image$$PT_PRIV_RWZI_START$$Base to Image$$PT_PRIV_RWZI_END$$Base)to be accessible only in UNPRIV state. * TFM_SP_META_PTR to be accessible in both PRIV and UNPRIV states. Also in this file mpu_armv8m_enable() function call specifies PRIVILEGED_DEFAULT_ENABLE for MPU. I have following question to this configuration * Does this configuration mean that in L3 PSA RoT code is not isolated from APP RoT (APP RoT can read/execute PSA RoT domain code)? * How SPM data (TFM_BSS and TFM_DATA sections from scatter file) is protected? I cant see it being protected by MPU. * Is it skipped because PRIVILEGED_DEFAULT_ENABLE is set which means that SPM will be able to access this data and this allows to save one MPU region? * If so then why MPU region is used for PSA RoT partitions data? 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>

3 years, 7 months

2
2
0 0

[RFC]Library Model deprecation

by Summer Qin

Hi, We plan to merge Library Model deprecation patches<https://review.trustedfirmware.org/q/topic:%22library-model-deprecation%22+…> this Friday since some other development work depends on this. May I ask for a review on these patches? Best Regards, Summer

3 years, 7 months

2
1
0 0

Open CI Infrastructure in Maintenance

by Xinyu Zhang

Hi, Open CI infrastructure is in an emergency maintenance. Tests will be impacted. I'll let you know once it is back to normal. Best Regards, Xinyu

3 years, 7 months

1
1
0 0

State of Extra tests

by Bohdan.Hunko＠infineon.com

Hi all, I have tried building Extra S and NS tests from tf-m-extras repo for PSoC64 and the result I got is that device prints message that extra S test started and reboots. Here is the command line I used: cmake -S . -B build_psoc64 -G "Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DTFM_LVL=2 -DEXTRA_S_TEST_SUITES_PATHS=< tf-m-extras path>/examples/extra_test_suites_example/extra_s -DEXTRA_NS_TEST_SUITES_PATHS=<tf-m-extras path>/examples/extra_test_suites_example/extra_ns I have also tries building with following command line (same as before but -DTEST_S=ON and -DTEST_NS=ON added): cmake -S . -B build_psoc64 -G "Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DTFM_LVL=2 -DEXTRA_S_TEST_SUITES_PATHS=< tf-m-extras path>/examples/extra_test_suites_example/extra_s -DEXTRA_NS_TEST_SUITES_PATHS=<tf-m-extras path>/examples/extra_test_suites_example/extra_ns -DTEST_S=ON -DTEST_NS=ON The result is the same - message about starting Extra S test suite is printed and then device reboots. Could someone please test it on other platform and let me know whether Extra S and NS tests works there. 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>

3 years, 7 months

2
1
0 0

Use original CMSIS files

by david.hazi＠arm.com

Hi all, We've created a change, which is using original CMSIS headers in TF-M. Current patch is only for arm/mps3/an552 platform. Our plan is to create a public review only for this (which will NOT be merged), and after the review, we would like to extend this patch to all of the platforms. The main changes in the chain: - copy and zero_table size fix in the GNU linker scripts and initial startup code - Removed __INITIAL_SP and __STACK_LIMIT patch form gcc and iar cmsis files, NS linker scripts using CMSIS style naming, the secure and bl2 build's linker scripts remains untouched (ARMCLANG style naming, __INITIAL_SP and __STACK_LIMIT patched with cmsis_stack_override interface library) - NS process stack removed from NS linkers (PSP) - Common startup file for bl2 and ns builds - Add original cmsis headers, updated system and startup files - Stack sealing done twice, once from startup (to resemble CMSIS startup template) and once from TF-M secure main Feedback is welcome: https://review.trustedfirmware.org/q/topic:%2522use-original-cmsis-headers%… David Hazi

3 years, 7 months

2
3
0 0

TF-M psa crypto test do not set the algorithms in psa_key_attributes_t

by Swarowsky, Markus

Hello, I was adding sanity checks to the psa_crypto_driver_wrappers to validate bits/type and policy->alg of the given psa_key_attributes_t attributes for the psa_generate_key, psa_import_key, and psa_copy_key calls. To check it the given combination is within the psa specification. In the PSA crypto spec it says: The key permitted-algorithm policy is required for keys that will be used for a cryptographic operation, see Permitted algorithms<https://armmbed.github.io/mbed-crypto/html/api/keys/policy.html#permitted-a…>. [https://armmbed.github.io/mbed-crypto/html/api/keys/management.html?highlig…] Which is most likely the case for all key types except of PSA_KEY_TYPE_RAW_DATA But after adding the sanity checks the TF-M crypto tests(test_c*_testing_* and TFM_S/NS_CRYPTO_TEST_10*) failed. I took a look at these tests, it turned out that they don't set the algorithm flag for the key attributes. My question now is, is the algorithm flag skipped on purpose or just missed during the test case creation as It should be set according to the psa crypto spec? Thanks for the help and the feedback Markus Swarowsky | R & D Engineer M +47 404 66 922 | Trondheim, Norway nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…> | devzone.nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevzone.n…> Facebook<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.faceb…> | LinkedIn<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linke…> | Twitter<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.c…> | YouTube<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtu…> | Instagram<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.insta…> [Nordic_logo_signature]<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…>

3 years, 7 months

2
5
0 0

TF-M Open CI Unstable

by Xinyu Zhang

Hi, TF-M Open CI is unstable for the time being because of the ArmClang license issue in Jenkins. Sorry for any inconvenience! I'll let you know once it is back to normal. Thanks, Xinyu

3 years, 8 months

1
1
0 0

[RFC]Moving faults handlers to dedicated file

by Kevin Peng

Dear platform owners, I'm moving faults handlers to dedicated files from spm_hal.c as this file should be for Library Model only. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/16858 Please check your platforms respectively. Plan to merge it on next Monday. Best Regards, Kevin

3 years, 8 months

1
0
0 0

Level 3 Isolation improvements

by Bohdan.Hunko＠infineon.com

Hi everyone, I have several questions related to L3 isolation in TFM. First of all, FFM specifies that: * In L3 PSA RoT partitions does not need to be isolated from SPM (and vice versa) * PSA RoT partitions does not need to be isolated from each other * PSA RoT partitions and SPM must be isolated from APP RoT partitions * APP RoT partitions must be isolated from each other This picture from TFM docs<https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig…> seem to illustrate statements above. Currently platforms with L3 support (e.g. an521) follow the rules stated above. They achieve this by executing PSA RoT partitions and SPM in privileged mode, and APP RoT partitions in unprivileged mode. Partition boundaries are only updated when switching to APP RoT partition. From description of tfm_hal_activate_boundary (see code here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>) and this an521 code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> seems like platform can determine whether partition will be executed in privileged or unprivileged mode. So my questions are: 1. For improved isolation in L3 does it make sense to: * isolate SPM from PSA RoT partitions * isolate PSA RoT partitions from each other (like APP RoT partitions are isolated) 1. If question 1 make sense then can platform achieve this improved isolation with current code base? From this an521 code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> it seems like platform may set all partitions to be executed in unprivileged mode and dynamically switch boundaries between them (between both PSA and APP RoT partitions). SPM will remain in privileged mode. It seems like this approach is possible with minor changes to SPM. For example this code will need<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…> to be changed to call tfm_hal_activate_boundary regardless of partition privilege level. Are there any other changes needed to make this approach work? 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>

3 years, 8 months

2
5
0 0

Enable stack protection in the regression tests

by Swarowsky, Markus

Hey, While trying to debug a crash in the TF-M regression tests, I noticed that the msplim_ns register is set to 0x0, leaving the non-secure application without any stack to protection, sadly I wasn't able to figure out how to enable the stack protection, which would be nice as we suspect that a stack overflow could cause the crash. Therefore, I would be interested if it possible to enable stack protection for the non-secure application of the TF-M regression tests and if so, how? Thanks for the help Markus Swarowsky | R & D Engineer M +47 404 66 922 | Trondheim, Norway nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…> | devzone.nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevzone.n…> Facebook<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.faceb…> | LinkedIn<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linke…> | Twitter<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.c…> | YouTube<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtu…> | Instagram<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.insta…> [Nordic_logo_signature]<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…>

3 years, 8 months

5
4
0 0

Partition assets attributes

by Bohdan.Hunko＠infineon.com

Hi everyone, I have several questions related to partition assets attributes. FFM specifies 2 types of assets (mmio_regions): * Named MMIO region * Numbered MMIO region FFM does not really specify the use cases for these 2 different types. I expect that Named region is only used for peripherals and numbered region is only used for memory regions. Am I right here? If no, then what the use cases for these 2 types are and what is currently supported in TFM? Also I see that in tools/templates/partition_load_info.template lines 221-224 ASSET_ATTR_NUMBERED_MMIO or ASSET_ATTR_NAMED_MMIO are assigned for assets from manifest files depending on their type, but tools/templates/partition_load_info.template#187<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/tools/temp…> does not assign any of these attributes for "PART_REGION_ADDR(PT_{{manifest.name}}_PRIVATE, _DATA_START$$Base)" at isolation level 3. Is this some a bug or I am missing some knowledge on this mmio_regions stuff? 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>

3 years, 8 months

2
3
0 0

TF-M Library model deprecation proposal

by Anton Komlev

Hello, Following tech forum today and the presentation on August 18 (to be published asap), I propose to deprecate TF-M library model as an obsolete and replace it with SFN model as a successor. PSA compliant SFN and IPC, defined in FF_M will then be the 2 supported models in TF-M going forward. Please share your thoughts and concerns on the proposal. Having no objections, we will depreciate the Library model after October 1 and it will be removed in TF-M v1.7.0 Thanks, and best regards, Anton

3 years, 8 months

1
1
0 0

Template implementations used in production

by Bøe, Sebastian

Hi, we wish to avoid the pitfalls of "doing your own security", and at the same time not use dummy/template code that is not meant for production. May I ask if it is still accurate what the docs say here about the template folder, namely that nothing in the template folder should be used in production without being ported first? This directory contains platform-independent dummy implementations of the interfaces in platform/include. These implementations can be built directly for initial testing of a platform port, or used as a basic template for a real implementation for a particular target. They must not be used in production systems. $ ls platform/ext/common/template/ attest_hal.c flash_otp_nv_counters_backend.c otp_flash.c tfm_initial_attest_pub_key.c crypto_keys.c flash_otp_nv_counters_backend.h tfm_fih_rng.c tfm_rotpk.c crypto_nv_seed.c nv_counters.c tfm_initial_attestation_key.pem tfm_symmetric_iak.key

3 years, 8 months

2
1
0 0

SFN non-secure interface sources

by Andersson, Joakim

Hi. I was testing the SFN model on the TF-M 1.6 release and I am confused about which API source files should be used for the non-secure application. The documentation here is lacking, so I am going by what we do in the build scripts of TF-M and tf-m-tests. The non-secure source files that are exported and included in the nonsecure API library are tfm_<partition>_ipc_api.c. This strikes me as odd, to use the IPC source files for the SFN model. If this is correct the naming is misleading. From the code the selection is done based on PSA_API definition. Based on this if this is the correct source files to use then I would think this should either be documented or renamed to something that better reflect the use, perhaps tfm_<partition>_psa_api.c? In the documentation there is a lot of room for improvements, the existence of tfm_<partition>_secure_api.c could lead to confusion since it is not always well described. tfm_attestation_integration_guide.rst: System integrators might need to port these interfaces to a custom secure partition manager implementation (SPM). Implementations in TF-M project can be found here: - ``interface/src/tfm_initial_attestation_func_api.c``: non-secure interface implementation for library model - ``interface/src/tfm_initial_attestation_ipc_api.c``: non-secure interface implementation for IPC model - ``secure_fw/partitions/initial_attestation/tfm_attestation_secure_api.c``: secure interface implementation Here it is not clear to me what "secure interface implementation" means, it could be interpreted as the SFN API. tfm_crypto_integration_guide.rst: - ``tfm_crypto_secure_api.c`` : This module implements the PSA Crypto API client interface exposed to the Secure Processing Environment Here it is clearer that tfm_<partition>_secure_api.c is the interface to the SPE. However the documented NSPE interface source file does not even exist, and does not explain the IPC / FUNC difference: | NSPE client API interface | This module exports the client API of PSA Crypto to the NSPE | ``./interface/src/tfm_crypto_api.c`` tfm_fwu_service.rst: | NSPE client API interface | This module exports the client API of PSA Firmware Update to | ``./interface/src/tfm_firmware_update_func_api.c`` | | | the NSPE(i.e. to the applications). | ``./interface/src/tfm_firmware_update_ipc_api.c`` | Here it is mentioned the two possible source files, but it is not specified when to use which source file. Generally: Between all the services this is not consistently listed, for example the tfm_its_service.rst file does not have the table of source files. If there is a general description of the non-secure interface sources, I couldn't find it. -Joakim AnderSSON

3 years, 8 months

2
1
0 0

Failure mode of protected storage with faulty NV counters?

by Jeremy Herbert

Hi, I am not too familiar with TF-M, so please forgive me if this is a silly question. The protected storage APIs appear to require the use of on-die flash to store a non-volatile counter that is used for rollback protection. This is severely limiting in terms of the number of writes, because basically you get as many writes as the endurance of the flash on the MCU (for example, the nordic cortex M33 devices have a rated write endurance of 10k cycles per page, and I don't think there is any wear levelling in TF-M). For example, assuming that a device was configured to write to the protected storage on boot, one could pretty easily exhaust this flash in a few hours by continuously power cycling it. Even if the 10k writes is a very conservative rating, it seems pretty likely that the counter flash will fail before UINT32_MAX. My question is: what happens to the security and functionality of the protected storage if the internal NV flash write fails silently? I don't know much about the semiconductor physics at play here, but presumably it could fail to make the counter a constant number, or fail to a random number. I had a quick look but there don't appear to be any checks in the code to ensure that a value was actually written correctly to the NV counters flash in case of silent corruption - it seems to just assume that any error would be detectable by some return code from the flash write driver. I was looking for some check like: if (value_to_write != value_read_back) return FLASH_WORN_OUT_ERROR; But I wasn't able to find it. So assuming it isn't actually there, if the counter fails to a constant (which is not UINT32_MAX) then presumably the rollback protection would be broken for all writes after that point (and maybe some before depending on the constant). If it fails to a random number, then it would be broken in a more "random" way - ie it would randomly work/not work depending on the value of the counter, until all UINT32_MAX numbers are randomly selected as the counter value. Also, given that typical AEAD ciphers like AES-GCM typically fail catastrophically with nonce reuse and the protected storage is indeed AEAD (though I can't quite work out yet which cipher is used), if these non-volatile counters are used to generate a nonce then potentially the encryption of the device could be broken just by rebooting the device until the flash is worn out, and then the nonce will be reused if the flash fails to a constant value. Could someone please help me clear up if my understanding here is correct? As is, I am struggling a bit to understand how to use the protected storage API in a secure way with this constraint, because if an attacker has any way to repeatedly cause a flash write it is basically game over. Any help would be greatly appreciated. Thanks, Jeremy

3 years, 8 months

4
15
0 0

Re: [TF-M] Supporting encryption with ITS

by Sherry Zhang

Hi George, The ITS without encryption is not a compromised RoT. In the PSA Secure Storage API spec, the PSA Internal Trust Storage aims at providing a place for devices to store their most intimate secrets. Also “””””””””””””””””””” 1. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from read and modification by attackers with physical access to the device. 2. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from direct read or write access from software partitions outside of the PSA Root of Trust (PRoT). “””””””””””””””””””” So, for internal trusted storage service, it requires the underlying storage itself should provide being read or write protection. The storage area should be a “trusted” area. Does the storage area on your device meet this requirement? Is the memory physically isolated? If not, I wonder why not uses the Protected Storage service instead? For the design of adding encryption in ITS, in the PS partition, the `iv` and the encrypted object data are stored with the object file while the tag of each object is stored with the object table file. So, if encrypt the PS object in the ITS file system, how the PS partition get the `tag` of each object? After a rough thought, I think probably a standalone encryption for ITS is more reasonable. As this is a relatively “big topic”, would you like to hold a discussion on the TF-M Tech forum if it is not limited by confidential information? The next Tech forum will be hold on this Thursday 3:00 PM UTC time. Regards, Sherry Zhang From: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Sent: Friday, September 24, 2021 8:52 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Supporting encryption with ITS Hello Sherry, Thank you for your input! 1. Our threat model is more concerned about attacks which can happen very early in the boot process, I think. A completely compromised RoT is not in our threat model. 2. I see that, ITS is supposed to store small objects. The storage overhead of adding encryption will be probably bigger than 20 bytes I think but the intention is to have this only as a configuration, not as the default option. 3. Agreed, a HAL API should be used for this. Do you have any opinion on the design of it? Do you think that it adds value to do try to use a common design for the object handling of both PS and ITS or is it better to have it as a standalone thing for the ITS. Regards, George ________________________________ From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Friday, September 24, 2021 11:58 AM To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Supporting encryption with ITS Hi George, Some comments from my side: 1. Internal trusted storage is part of the Root of Trust domain. If ITS storage device is attacked, then the code flash where the PSA Rot SP locates may also be attacked. Does the thread model of your system require the encryption in ITS? 2. The ITS service is intended to be used to interface to a small piece of storage. Encryption would increase the context for each ITS file. For example, similarly to PS object context, the `IV` which is used in encryption as well as the generated `tag` should be added into each file context. They total together can be about more than 20 bytes. 3. If the encryption is mandatory/ necessary required by the thread model of your system, as discussed, the PSA crypto service should not be called to avoid the circular. I think a HAL API for encryption may be created in ITS for platform implementation defined encryption/decryption. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M Sent: Thursday, September 23, 2021 10:47 PM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting encryption with ITS Hey Gyorgy, These are very valuable comments! I am aware of the circular dependency issue because the PSA apis are using the ITS as a storage backend. This, as you said, can be circumvented by using a software crypto library or an implementation specific API. So, for the encryption a flexible API can be used which can allow externals to use their own function calls. Regarding the key storage, this is what I had in mind as well, using derived keys from the HUK. So that we don't need to store anything but the crypto metadata. Adding another layer of storage will raise more issues, I think. ________________________________ From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Thursday, September 23, 2021 4:30 PM To: Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>>; Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Supporting encryption with ITS Hi, AFAIK the main reason for ITS not using encryption is the problem of circular dependency. ITS is used by crypto SP for key storage, so how will crypto fetch the key from ITS to decrypt ITS? You could use a software crypto implementation (another mbed-tls instance) in ITS, but where would you safely store the keys? If you have a two layer ITS, one for only storing the keys for the second instance, and a second, encrypted one, then you end up with something like ITS and PS. You may not need a full blown on-chip FLASH device for ITS. If you have a HUK available, you can derive the same SP specific keys from that at each boot, and store these in RAM backed ITS. You won’t be able to store other keys in ITS in a persistent way of course, but for that you can use PS. Well, something along these lines. Perhaps the TF-M team could help better if you could share some details on why your customer would need encrypted ITS. (A PSA for Cortex-A (TS) maintainer chiming in to a “not his business” discussion here 😉 ) /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Fabian Schmidt via TF-M Sent: September 23, 2021 15:51 To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting encryption with ITS Hi George, I’m wondering if that would add value. To my understanding, ITS was never designed to be encrypted because of the way it’s supposed to be set up. (It’s Internal Trusted Storage.) I believe best practice is to place it in a “trusted” location, one that is ideally only accessible from Secure world, and also ideally on-die. If you then restrict outside access to the internal flash (JTAG, flash programmer ports,…), you’re pretty golden, in that no unauthorized party should be able to read from or write to the ITS.* Let me know if I misunderstand anything about ITS or TrustZone, but that’s my view. Maybe I’m painting an idealized picture. Greetings, Fabian Schmidt * at least short of a sophisticated physical attack or finding some loophole in TrustZone… From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M Sent: Donnerstag, 23. September 2021 15:28 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [EXT] [TF-M] Supporting encryption with ITS Caution: EXT Email Hey all, Lately the requirement for an encrypted ITS solution is being asked from our customers and I would like to have a discussion here on how we can design this in a reasonable way. The first thought that came to my mind was to add the functionality to the ITS flash-fs layer. This layer contains file metadata in the its_file_meta_t structure and it should be possible to expand this to include additional crypto metadata (conditionally). This seems to be the less invasive change to me, even though it will introduce some increased memory usage since supporting encryption will mean that we cannot read the data in chunks anymore, we will have to use static buffers. At the same time, I looked at the PS partition since I knew that it has support for encryption. I believe that some core concepts of both solutions have similarities even though the code is quite different. For example, a file in ITS is similar to an object in PS and the (linear) list of file metadata in ITS is similar to the concept of the object table in PS. So, I think that it should be possible to design some generic-enough APIs that we can use for both the ITS and PS. Even though this will require some major refactoring in both partitions, it will decrease the code of these services which will probably decrease maintenance later. What are your thoughts on this? Regards, George

3 years, 8 months

6
16
0 0

Re: Status of RSS platform?

by Maulik Patel

Hi Chris, RSS build requires new runtime Measured Boot Service. This service partition is not yet part of PSA specification and hence it resides in the tf-m-extras repository. (https://git.trustedfirmware.org/TF-M/tf-m-extras.git/) For out of tree partition build, if you map the tf-m-extras repo and provideTFM_EXTRA_MANIFEST_LIST_FILES =<path_to_measured_boot_manifest_list.yaml> and TFM_EXTRA_PARTITION_PATHS=<path_to_measured_boot_partition> (example as below), then it should fix build issue. -DTFM_EXTRA_MANIFEST_LIST_FILES=../../tf-m-extras/partitions/measured_boot/measured_boot_manifest_list.yaml -DTFM_EXTRA_PARTITION_PATHS=../../tf-m-extras/partitions/measured_boot If the error persists, could you please send me the build options you are using and I'll look into this further. Best Regards, Maulik ________________________________ From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org> Sent: Wednesday, September 7, 2022 1:00 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Digest, Vol 47, Issue 7 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Status of RSS platform? (Chris.Brand(a)infineon.com) ---------------------------------------------------------------------- Message: 1 Date: Tue, 6 Sep 2022 21:48:05 +0000 From: <Chris.Brand(a)infineon.com> Subject: [TF-M] Status of RSS platform? To: <tf-m(a)lists.trustedfirmware.org> Message-ID: <2441d128df93483abc1da39c38e89885(a)infineon.com> Content-Type: multipart/alternative; boundary="_000_2441d128df93483abc1da39c38e89885infineoncom_" Hi, I'm wondering what the status of the RSS platform is. I tried to build it from the current HEAD of master and also from a few earlier commits, and cannot get it to build (I get an error about TFM_MEASURED_BOOT_SID being undeclared in some of the generated code). I was curious about the implementation of tfm_hal_get_mem_security_attr(), tfm_hal_get_secure_access_attr() and tfm_hal_get_ns_access_attr() on an ARMv8 multi-core platform, but there doesn't currently seem to be an implementation of those HAL functions. Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com<http://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.

3 years, 9 months

3
3
0 0

TF-M configurability

by Anton Komlev

Hello, Recently we discussed the movement of relevant options into C header files as a potential configuration improvement. By this mail thread, I would like to provoke discussion on what else we are lacking in TF-M configurability and thoughts to make it better. Please share your ideas to review them in the upcoming tech forum. Thanks, Anton

3 years, 9 months

2
2
0 0

Status of RSS platform?

by Chris.Brand＠infineon.com

Hi, I'm wondering what the status of the RSS platform is. I tried to build it from the current HEAD of master and also from a few earlier commits, and cannot get it to build (I get an error about TFM_MEASURED_BOOT_SID being undeclared in some of the generated code). I was curious about the implementation of tfm_hal_get_mem_security_attr(), tfm_hal_get_secure_access_attr() and tfm_hal_get_ns_access_attr() on an ARMv8 multi-core platform, but there doesn't currently seem to be an implementation of those HAL functions. Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> 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.

3 years, 9 months

2
1
0 0

Reproducible test builds

by Bøe, Sebastian

Hello, when building TF-M you get the same result no matter what computer you build from assuming all the tooling is the same version. The builds are reproducible in other words. But when building TF-M together with the tests, e.g. by building the regression test suite you will get a different binary depending on where in the filesystem the tf-m-tests repository has been installed. This is because the TEST_FAIL macro uses the gcc macro _FILE_ which injects the absolute paths of source files into strings in the binary. This is a big problem for people using CI systems as a different sized binary can affect race conditions, flash region usage overflows, etc.. I think we should make builds reproducible by default, possibly with a configuration for adding absolute paths into the binary for those that prefer so. I would like to write a patch to this affect, but would prefer to get some feedback now so I don't have to re-write it in review. The simplest solution is to remove __FILE__ from the TEST_FAIL macro,but this would remove useful information and may also fail in the future if someone else uses __FILE__. The more common way of solving this problem is to add a flag to the compiler that instructs it to replace any occurrences of the absolute path with something else during macro expansion. For instance replace "C:/repos/tf-m-tests/source_file.c" with "TFM_TESTS/source_file.c". For gcc the flag is -fmacro-prefix-map=<old_string>=<new_string>. I don't know what the flag is for the other supported compilers or if they support it at all. Would it be OK to only support reproducible builds for the compilers that support an equivalent of macro-prefix-map?

3 years, 9 months

2
4
0 0

What do you think using configuration headers in TF-M ?

by Anton Komlev

Hello, TF-M has many options to configure. All of them are declared as a CMake variables and many of them translated to compiler definitions later. Since the idea of TF-M configuration via config header file(s) was warmly received on the last tech forum I would like to check with community opinion on such hypothetical move: Configure TF-M via definitions in header files while leave CMake for a building control only. Please share your thoughts, opinions and the possible dependencies. Thanks, Anton

3 years, 9 months

6
9
0 0

[RFC] Fault Injection Hardening (FIH) re-enablement on AN521 are ready for review

by Ken Liu

Hello, The FIH functionality reference implementation on AN521 was there before, and then get turned off last year because it increases the effort of updating the HAL interface. Now the HAL interface update is done, this functionality is re-enabled on AN521, based on the updated HAL. The patches are pushed for your review: https://review.trustedfirmware.org/q/topic:%22FIH_AN521_RE%22+(status:open%… The mechanism is mainly the same as the previous implementation, The document is under modifying to reflect the re-enablement changes but still can be read to recall the general concept: https://tf-m-user-guide.trustedfirmware.org/technical_references/design_doc… Please leave your comments in the patches or do overall discussions in this mail thread. Thanks! /Ken

3 years, 9 months

1
0
0 0

AN524 Flash_Driver issue consult

by jidong.mei＠armchina.com

Hi All : I'm developing Flash Driver for TF-M AN524 demo , and trobuled by some code logic . It's that : For , AN524 , PS storage Area is redirect to BRAM , so PS area related read and write can be done using memcpy without Flash driver being implementened . see : platform/ext/target/arm/mps3/an524/cmsis_driver/Driver_Flash.c /* Redirecting PS storage to BRAM */ if (addr >= FLASH_REDIRECT_BASE && addr <= FLASH_REDIRECT_LIMIT) { start_addr = FLASH_REDIRECT_DEST + (addr - FLASH_REDIRECT_BASE); /* PS Flash is emulated over BRAM. use memcpy function. */ memcpy((void *)start_addr, data, cnt); } else { /* Flash driver for QSPI is not ready */ return ARM_DRIVER_ERROR_UNSUPPORTED; } My question is : What the purpose of "else" branch above ? After I implement QSPI driver , in "if" branch , I remove redirect operation , and use Flash Write APIs to replace memcpy func. Then , shoud "else" branch be removed? Or , should I put Flash write driver in "else" branch , and keep "if" branch the same with origion? Best regards, Jidong Mei

3 years, 9 months

2
2
0 0

CMSIS in TF-M

by Chris.Brand＠infineon.com

TF-M includes platform/ext/cmsis, which is CMSIS v5.9.0 with some TF-M-specific changes. Looking at the history for that directory, it seems that we periodically update it and have to re-apply the TF-M-specific changes (which looks to be the naming of the stack and the copy table size). I'm wondering whether there's a plan to either push the TF-M changes into upstream CMSIS or to change TF-M so that they're not needed? It would be nice to just pull CMSIS from upstream like we do with other external libraries... Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> 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.

3 years, 9 months

2
1
0 0

ITS/PS improvements

by Roman.Mazurak＠infineon.com

Hello all, I made a patch (https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/16214) that reorganize interaction between ITS partition, ITS file system and ITS flash driver. 1. ITS flash driver interface is decoupled from ITS file system. 2. ITS flash driver interface isn't dependent on upper layers like ITS FS or ITS. 3. ITS flash driver emulated in RAM (its_flash_ram) can be used without CMSIS flash driver even in production environment if needed. 4. Target can provide own implementation of ITS flash driver without implementing CMSIS flash driver. Which can be more flexible or simple in some cases. 5. Allocation of ITS flash driver instance by ITS partition is not dependent on lower layers like CMSIS driver. ITS partition uses abstract flash driver interface to bind ITS file system and driver instance. This changes gives following benefits. 1. Vendors can provide ITS flash driver without need to create an intermediate CMSIS flash driver. 2. It's possible to implement ITS encryption by adding a new ITS flash driver that performs encryption and uses existing drivers (NOR, NAND, RAM, platform specific) as the storage backend. 3. It's possible to use ITS file system + ITS encryption driver (b) for Protected Storage directly without additional context switching during access to PS file system handled by ITS partition. I think it should improve performance of PS. 4. Use ITS file system directly in application specific custom partitions by allocating ITS file system context and ITS flash driver. Best regards, Roman.

3 years, 10 months

1
0
0 0

Service vs Partition wording in manifest files

by Bohdan.Hunko＠infineon.com

Hi everyone, From what I see manifest lists (e.g. tools/tfm_manifest_list.yaml) describe partitions, but "name" field there (which is a description of the partition) uses "Service" word, for example: "name": "Protected Storage Service", Shouldn't this be "name": "Protected Storage Partition" ? Why do TFM uses Service when describing the Partition? 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>

3 years, 10 months

3
12
0 0

TF-M Tech Forum minutes / upcoming Tech Forums calendar

by Don Harbin

Hi All, A gentle reminder that past TF-M Tech Forum minutes/recordings including the last one from August 4th can be found *here <https://www.trustedfirmware.org/meetings/tf-m-technical-forum/>* . Also, the public calendar that includes upcoming TF-M tech forums can be found *here* <https://www.trustedfirmware.org/meetings/>. Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years, 10 months

1
0
0 0

Request about local test with IAR compiler

by Jianliang Shen

Hi, I made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/16106> to change CMSIS-RTOS RTX library attribute for ARMv8-M Mainline platforms in TF-M, the reference is CMSIS-RTOS2<https://www.keil.com/pack/doc/CMSIS/RTOS2/html/pDirectory_Files.html#libFil…>. As CI doesn't cover IAR compiler, I'm very grateful if someone who is convenient can help me build and run it with IAR toolchain locally. Best Regards Jianliang Shen

3 years, 10 months

1
0
0 0

Proposal for coding standard update: Increase chars per line 80-> 128.

by Anton Komlev

Hi, TF-M coding standard<https://tf-m-user-guide.trustedfirmware.org/contributing/coding_guide.html> mandates up to 80 characters per line. This looks a bit too restrictive nowadays with no punch cards or text terminals. I propose to increase this limit to 120 or 140 characters. Personally like 128. Are there any thoughts or objections against it? Thanks, Anton

3 years, 10 months

6
7
0 0

Example Partition Updates

by Kevin Peng

Hi all, Please be noted that the TF-M example Secure Partition has been moved from the tf-m-tools repo to the tf-m-extras<https://git.trustedfirmware.org/TF-M/tf-m-extras.git/tree/examples/example_…> repo. It has also been aligned with the latest TF-M. The documentations are improved as well. It could be a good reference for Secure Partition developer starters. Best Regards, Kevin

3 years, 10 months

2
2
0 0

Documentation improvements

by Anton Komlev

Hello, The project documentation will never be ideal and we are continuing improving it. Let me ask you for reply to this email with the pain points you have experienced or suggestions for improvements to be considered in this phase. Your direct contribution with docs articles will be much appreciated too. For example: TF-M debugging technics and experience would be very helpful. Thank you in advance, Anton

3 years, 10 months

3
3
0 0

TF-M CI build failures in master

by Andersson, Joakim

It looks like the TF-M CI has build failures in the master branch. The build log for tf-m-build-and-test has a lot of build errors: https://ci.trustedfirmware.org/blue/organizations/jenkins/tf-m-build-and-te… The following message is printed: [2022-08-01T11:14:49.204Z] Exception: Invalid "conditional" attribute: "TEST_NS_CORE" for TFM Core Test Service. Please set to one of ['on', 'true', 'enabled'] or ['off', 'false', 'disabled', ''], case-insensitive. [2022-08-01T11:14:49.204Z] CMake Error at tools/CMakeLists.txt:158 (message): [2022-08-01T11:14:49.204Z] File generation failed The top commit on master looks like a likely candidate for this problem: commit 56979ee5579dbb90bbf598af4c252259e5f20777 (tfm/master) Author: Kevin Peng kevin.peng(a)arm.com<mailto:kevin.peng@arm.com> Date: Thu May 12 12:11:31 2022 +0800 Tools: Pass build configurations through header file This patch adds a new configuration header file argument for the manifest tool. For example, this PR is triggering the issue: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/16110 Joakim Andersson | Senior R&D Engineer Trondheim, Norway nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…> | devzone.nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevzone.n…> Facebook<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.faceb…> | LinkedIn<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linke…> | Twitter<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.c…> | YouTube<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtu…> | Instagram<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.insta…> [Nordic_logo_signature]<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…>

3 years, 10 months

3
3
0 0

[RFC]Decoupling manifest tool with build system

by Kevin Peng

[Thread res-used, title renamed] Hi all, This is now happening - fully support non-CMake use of the manifest tool. Here is the patch: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15756 With this patch, the manifest tool takes build configurations from a config header file instead of replying on the build system. Please check the details in the patch. Any comments are welcome. Best Regards, Kevin -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Thursday, May 12, 2022 2:49 PM To: Kevin Peng <Kevin.Peng(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: RE: Any usage of environment variables in manifest lists > If there are strong requirements on supporting the non-cmake usecase Yes, it is 😉 -----Original Message----- From: Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, May 12, 2022 5:46 AM To: Kevin Peng <Kevin.Peng(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Re: Any usage of environment variables in manifest lists Well, I think I figured out a way to decouple them. If there are strong requirements on supporting the non-cmake usecase, I can try to work it out. Best Regards, Kevin -----Original Message----- From: Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, May 12, 2022 10:09 AM To: Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Re: Any usage of environment variables in manifest lists Yes. The manifest tool is now fully replying on CMake (it has been, since I introduced the conditional parsing of manifests around half a year ago). It needs to be aware of the build configurations. Best Regards, Kevin -----Original Message----- From: Raef Coles <Raef.Coles(a)arm.com> Sent: Wednesday, May 11, 2022 7:15 PM To: tf-m(a)lists.trustedfirmware.org; Kevin Peng <Kevin.Peng(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: Any usage of environment variables in manifest lists Hey Kevin Does this mean that cmake will be required to generate the headers/etc from the manifests? I believe in the past we deliberately supported the non-cmake usecase, as some people were building TF-M in alternate ways. Raef ________________________________________ From: Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 11 May 2022 09:24 To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [TF-M] Any usage of environment variables in manifest lists Hi, Is there anyone using environment variables for the "manifest" attribute in out-of-tree manifest lists? I'm asking because I'm working to support configurable stack_size for Secure Partitions<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>. In the patch the support of environment variables in manifest lists is removed<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>. Because I have to call the CMake command configure_file to replace the stack_size symbols (CMake variables<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> surrounded with "@") with their values. While configure_file does not recognize environment variables. If you do have environment variables in manifest list, there is an alternative: Replace the env. variables with CMake variables surrounded with "@" and set the value of the CMake variables in either config files or command line inputs. Best Regards, Kevin -- 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

3 years, 10 months

1
1
0 0

Intended use of psa_reset_key_attributes()

by S Krishnan, Archanaa

Hi, What was the intended usage of psa_reset_key_attribute(*attributes) which requires a PSA call from non-secure side to reset the client attributes? I am curious because the attributes to be reset comes from the non-secure memory, not directly associated with ITS/PS. The current IPC setup performs a PSA call to tfm_crypto_rest_key_attributes()(https://git.trustedfirmware.org/TF-M/trust… This function creates a copy of client key attribute in a secure key attribute structure. The secure key attribute is reset (set to 0) and then copied back to the client key attribute before returning to non-secure code. At first glance, this seems like a roundabout way to zeorise client side attributes. Regards, Archanaa

3 years, 10 months

2
3
0 0

FW: [Tf-openci-triage] [Maintenance] - ci.staging.trustedfirmware.org down time 2022-07-22

by Xinyu Zhang

Hi All, FYI. Open CI will be down from 2022 07-22 18:00 UTC to 2022-07-22 22:00 UTC for Jenkins upgrade. Please let us know if there is any problem. Thanks Xinyu -----Original Message----- From: Kelley Spoon via Tf-openci-triage <tf-openci-triage(a)lists.trustedfirmware.org> Sent: Thursday, July 21, 2022 10:14 PM To: tf-openci(a)lists.trustedfirmware.org; tf-openci-triage(a)lists.trustedfirmware.org Subject: [Tf-openci-triage] [Maintenance] - ci.staging.trustedfirmware.org down time 2022-07-22 Hello All, The server will be offline to start a maintenance window on 2022-07-22 at 20:00 UTC. Jenkins will be put into "Shutdown Mode" at 2022-07-22 18:00 UTC to stop accepting new jobs and allow executing tasks to complete. This downtime is required to add a plugin to Jenkins to support new functionality required for a service being developed. The version of Jenkins and the plugins currently being run will not be changing. Emails will be sent prior to and following the upgrade to provide status reports. Start: 2022 07-22 18:00 UTC End: 2022-07-22 22:00 UTC Regards, -- Kelley Spoon <kelley.spoon(a)linaro.org> -- Tf-openci-triage mailing list -- tf-openci-triage(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-triage-leave(a)lists.trustedfirmware.org

3 years, 10 months

1
0
0 0

ns_agent flag

by Chris.Brand＠infineon.com

In https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.… Ken mentions the need for a special flag in the manifest to indicate a non-secure agent partition. The code change is fairly easy, I think, but the manifest file format is specified by PSA, and presumably would also need to change. How do we go about doing that? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> 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.

3 years, 10 months

2
1
0 0

Last call for comments on patch 15362

by Chris.Brand＠infineon.com

Hi, We'd like to merge https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15362 which makes a small modification to all platform configs (TFM_CONFIG_USE_TRUSTZONE and TFM_MULTI_CORE_TOPOLOGY lose their default values and must be specified for every platform). Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> 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.

3 years, 10 months

1
0
0 0

Re: [TF-A] Re: Rebooting LTS discussion

by Varun Wadekar

Hi Everyone, We presented a proposal at the Tech Forum yesterday to take the LTS idea forward. The recording link and password are provided below. This effort is important for the project, and we don't want to rush into something that is not useful. With holidays and other engagements, we want to provide more time to digest the information and provide feedback. We will schedule another Tech forum discussion in September to hear feedback/concerns/questions. See you soon! -Varun Recording: https://linaro-org.zoom.us/rec/share/wYFz4jQvpLZntYSamyjc5-n_bGNcx_RFm-amEd… Passcode: NUx82^W= From: Joanna Farley <Joanna.Farley(a)arm.com> Sent: Wednesday, 22 June 2022 3:05 PM To: Varun Wadekar <vwadekar(a)nvidia.com>; Okash Khawaja <okash(a)google.com> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com>; tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Re: Rebooting LTS discussion External email: Use caution opening links or attachments Hi Everyone, I learnt today that our peer project (TF-M) are having a similar LTS discussion and have their own LTS Tech forum session tomorrow. Its an 8am BST(GMT+1) meeting start but I'm told the LTS discussion is mid agenda so expect the discussion on that to start around 8:30am. I'm told it's an information gathering session rather than a proposal session. Anyway the Zoom id of the call is below. These are recorded like TF-A sessions and will be uploaded to their Techforum page. Joanna This event has been changed with this note: "Extending end date" TF-M Tech forum When Changed: Every 4 weeks from 12am to 1am on Thursday Mountain Standard Time - Phoenix Where https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinaro-or…> (map<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…>) Calendar anton.komlev(a)arm.com<mailto:anton.komlev@arm.com> Who * Don Harbin - creator * tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> * anton.komlev(a)arm.com<mailto:anton.komlev@arm.com> * leonardo.sandoval(a)linaro.org<mailto:leonardo.sandoval@linaro.org> * abdelmalek.omar1(a)gmail.com<mailto:abdelmalek.omar1@gmail.com> more details ><https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> 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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> ====Zoom==== Topic: TF-M Tech forum - Asia Time Zone Friendly Time: Nov 12, 2020 07:00 AM Greenwich Mean Time Every 4 weeks on Thu, until Mar 4, 2021, 5 occurrence(s) Nov 12, 2020 07:00 AM Dec 10, 2020 07:00 AM Jan 7, 2021 07:00 AM Feb 4, 2021 07:00 AM Mar 4, 2021 07:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> Join Zoom Meeting https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> Meeting ID: 925 3579 4925 Passcode: 414410 One tap mobile +12532158782,,92535794925# US (Tacoma) +13462487799,,92535794925# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 925 3579 4925 Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> Going (anton.komlev(a)arm.com<mailto:anton.komlev@arm.com>)? All events in this series: Yes<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> - Maybe<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> - No<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> more options ><https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> Invitation from Google Calendar<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> You are receiving this courtesy email at the account anton.komlev(a)arm.com<mailto:anton.komlev@arm.com> 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://calendar.google.com/calendar/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.g…>. From: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> Date: Tuesday, 21 June 2022 at 18:11 To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>, Okash Khawaja <okash(a)google.com<mailto:okash@google.com>> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] Re: Rebooting LTS discussion Thanks Varun and Okash. I'll update Jul 14th invite and add LTS as the discussion area. From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Date: Tuesday, 21 June 2022 at 17:24 To: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>, Okash Khawaja <okash(a)google.com<mailto:okash@google.com>> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: RE: [TF-A] Re: Rebooting LTS discussion Hi Joanna, Thanks for the update. Okash and I would be ready by July 14. We will prepare the slides for the session. -Varun From: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> Sent: Tuesday, 21 June 2022 5:07 PM To: Okash Khawaja <okash(a)google.com<mailto:okash@google.com>>; Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Re: Rebooting LTS discussion External email: Use caution opening links or attachments Okash, Varun, Any thoughts when you want to do a LTS TechForum session. 30th June is now taken and the next scheduled one after that is 14th July. We could try and do a special one on 7th July if that's better. I'm reliant on you guys to jointly prepare and present a LTS TF-A Tech forum session Joanna From: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Date: Monday, 6 June 2022 at 13:47 To: Okash Khawaja <okash(a)google.com<mailto:okash@google.com>> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Re: Rebooting LTS discussion Hi Okash, The next session after next week is Thursday 30th June at 4pm BST. This is also available with nothing currently scheduled. Joanna From: Okash Khawaja <okash(a)google.com<mailto:okash@google.com>> Date: Monday, 6 June 2022 at 13:34 To: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> Cc: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>, Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] Re: Rebooting LTS discussion Hi Joanna and Varun, Sounds good to me. I will be out of country during next week. After that should be fine. Thanks, Okash On Mon, Jun 6, 2022 at 12:13 PM Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> wrote: Varun, Okash, I believe the two of you have some interest in the LTS topic. Would the two of you be willing to jointly prepare and present a TF-A Tech forum session? The next available session is Thursday 16th June at 4pm BST. I'm sure there are many definitions of what a LTS release branch is in terms of purpose, content, duration etc. I would expect many platform providers are doing this downstream today and I could imagine there may be variations. Some degree of consensus on how this is managed and resourced would be needed I believe between multiple platform providers who would want to consume this. It would be good to see issues raised for discussion. I'm happy to host if the two of you and any other platform providers interested can prepare a TF-A session to present to the broader TF-A community. Thanks Joanna From: Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Date: Tuesday, 31 May 2022 at 15:23 To: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, Okash Khawaja <okash(a)google.com<mailto:okash@google.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Re: Rebooting LTS discussion Hi Matteo/Okash, Thanks for re-starting the discussion. We (NVIDIA) are still interested in the idea and would like to discuss the next steps. I like the idea of a hotfix release, although would propose back-porting fixes to more tags. A targeted tech forum or another mechanism works for me. I would like to discuss the scope of the activity and the engagement model. -Varun -----Original Message----- From: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>> Sent: Tuesday, 17 May 2022 3:39 PM To: Okash Khawaja <okash(a)google.com<mailto:okash@google.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>; raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> Subject: RE: [TF-A] Rebooting LTS discussion External email: Use caution opening links or attachments Hi Okash, Thanks for rebooting the conversation. Out of the brainstorming from 1.5 yrs ago, we had this page published with an initial RFC proposal for LTSs: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…> Worth mentioning that, in the meanwhile, the TF-M project has introduced the concept of Hotfix releases (which is a very lightweight process for backporting critical bug fix/security fixes only to the last available tagged release): https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…> I'm curious to hear others' opinion and interest (@Varun, @Raghu ?) to possibly revive this topic in either in a Tech Forum or at a project TSC/Board level. Thanks Matteo -- TF-A mailing list -- tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org<mailto:tf-a-leave@lists.trustedfirmware.org>

3 years, 11 months

2
1
0 0

Partition priority questions

by Bohdan.Hunko＠infineon.com

Hi everyone, TFM manifest files allow to specify priority for the partition. FFM 1.0 and FFM 1.1 specify that there are 3 possible values for this field: Low, NORMAL, HIGH. This field is used in several template files to generate needed for SPM information. From what I see there are several problems with current implementation: 1. In secure_fw/spm/cmsis_func/tfm_spm_db_func.inc.template priority field is used to generate .partition_priority filed of spm_partition_static_data_t structure. It uses TFM_PRIORITY() macro to convert priority to numeric value. The problem is that this field is actually never used, instead all priority checking is done using .flags field of partition_{{manifest.name|lower}}_load_info_t structure (tools/templates/partition_load_info.template file). 2. .flags field uses PARTITION_PRI_ macro to convert priority to numeric value. Possible values for TFM_PRIORITY() are: LOW, NORMAL, HIGH, but PARTITION_PRI_ macro has: LOWES, LOW, NORMAL, HIGH, HIGHEST priorities. More over priorities with same names for these 2 macros have different numeric values (e.g. PARTITION_PRI_LOW is 0x7F while TFM_PRIORITY_LOW is 0xFF) 3. Scatter files does not account for HIGHEST priority (see code here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…>). This is a problem for all toolchains including both common scatter files (L1 and L2) and scatter files templates for L3 So I have several questions on this topic: 1. Are LOWEST and HIGHEST priorities system reserved? Because for now they cant be used in manifest files as TFM_PRIORITY() does not have support them. 2. Should TFM_PRIORITY() macro and .partition_priority filed of spm_partition_static_data_t structure be removed? This will mean that if LOWEST and HIGHEST priorities are system reserved then validation of value for "priority" manifest field should be added to tfm_parse_manifest_list.py 3. Should scatter files be fixed to account for HIGHEST priority? 4. secure_fw/partitions/ns_agent_tz/load_info_ns_agent_tz.c for NS agent TZ specifies (PARTITION_PRI_LOWEST - 1) for a .flags filed. Higher priority numeric values is lower real priority, which means that TZ NS agent partition priority is between LOW and LOWEST priority. This seems like a hack to me, maybe we should introduce One more named priority? 5. In secure_fw/partitions/CMakeLists.txt idle partition is included when IPC backend is used. Idle partition is used to retrigger scheduling before going into WFI state (just to be sure that higher priority partitions were executed and there is not pending request). I can see how this partition is useful for MULTICORE case, to have kind of sleep state. But for TZ case TZ ns agent is always RUNNABLE and have higher priority that IDLE partition so it does not look like IDLE partition will ever be scheduled in TZ case. In such case condition in this Cmake file should be changed from "if (CONFIG_TFM_SPM_BACKEND_IPC)" to "if (TFM_PARTITION_NS_AGENT_MAILBOX)" Am I wrong somewhere? Sorry, I know that is a lot of questions, but this scheduling stuff is really hard to wrap a head around. 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>

3 years, 11 months

2
2
0 0

PSA arch test problem

by Bohdan.Hunko＠infineon.com

Hi, Lately I have been working with PSA arch tests and found few issues with them: 1. PSA arch tests build on Windows fails. I am using the following command: cmake -S . -B build_gcc_psoc64 -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DTEST_PSA_API=INITIAL_ATTESTATION This is true for all the compilers and build types. I have also tried building Musca B1 and the results are the same. Is this expected behavior? Are PSA arch test meant to be built on windows? 2. I have tried building PSA arch tests with IAR on both Linux and Windows and it does not work. From quick investigation it looks like IAR is not supported. Am I right? And if so the is there a plan to support PSA arch tests for IAR compiler? 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>

3 years, 11 months

6
15
0 0

Proposal for Musca-B1 SE deprecation

by Anton Komlev

Hello, We would like to propose removing the Musca-B1 Secure Enclave platform configuration* in TF-M. This solution was developed to demonstrate the PSA Configuration to support the TF-M Secure Services on Secure Enclave providing Secure Services to the Host processor running non-secure application. Musca-B1 SE was the foundation of the Corstone-1000** solution, which provides a secure enclave implementation that is also PSA L2 Ready Certified. Please reply if there are any concerns deprecating and removing the Musca-B1 SE configuration from TF-M . Process for deprecation and removal of platforms can be found here https://tf-m-user-guide.trustedfirmware.org/platform/ext/platform_deprecati… * https://tf-m-user-guide.trustedfirmware.org/platform/ext/target/arm/musca_b… ** https://tf-m-user-guide.trustedfirmware.org/platform/ext/target/arm/corston… Thanks, Anton

3 years, 11 months

1
1
0 0

Manifest files questions

by Bohdan.Hunko＠infineon.com

Hi everyone, I have several questions related to manifest files in TFM: 1. Currently TFM dos not support dynamic memory allocation, so heap_size manifest field is a bit special. Presence of heap_size field for library model will generate error in tfm_spm_db_func.inc.template but when TFM_PSA_API is ON heap_size is used in partition_load_info.template which will silently set .heap_size struct field to 0 without generation of any error. As dynamic memory allocation is not supported I think error should be generated in both files. Also I think that error should only be generated if heap_size filed is present and is not "0" (if it is not present or is 0 then no error should be generated because it is compliant with "no dynamic memory rule") 2. Manifest files support numbered mmio regions for partitions. Example "mmio_regions": [ { "base": "MY_CUSTOM_REGION_BASE", "size": "MY_CUSTOM_REGION_SIZE", "permission": "READ-WRITE" } ] The questions is why doesn't TFM use this field for ITS and PS areas instead of handling them manually? Can this be reworked to use mmio regions? If so then is this work planned and when approximately it will be done? 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>

3 years, 11 months

2
1
0 0

Library fetching improvements

by Bohdan.Hunko＠infineon.com

Hi, Recently I have been adding some new libraries to my TFM project and what I always end up doing is: go to some existing file which fetches the library, copy code from there, paste it to my file, change few links, versions and names. It is a bit annoying to copy-paste that code each time, also it is hard to maintain (if pattern for fetching libraries changes) and also copy pasting might lead to some code not being updated. My proposal is to have a function that can be used to fetch a library. This way it will be easier to add new libraries and this change will make code cleaner. Please let me know your thoughts on this proposal. 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>

3 years, 11 months

5
8
0 0

Automatically copy RAM_VECTORS when using ARMClang and IAR

by Bohdan.Hunko＠infineon.com

Hi, When poking around some startup files I have found interesting place related to RAM_VECTORS support CMSIS have __PROGRAM_START macro which is different for each compiler. For GCC it uses __cmsis_start, for ARMClang - __main and for IAR - __iar_program_start Basically each of the functions should copy several sections (.TFM_DATA for example) from FLASH to RAM and zero out some parts of RAM (for .TFM_BSS for example) In current implementation GCC __cmsis_start function also copies the vector table from FLASH to SRAM (if RAM_VECTORS are enabled) But ARMClang and IAR equivalents of that function (__main, __iar_program_start) does not seem to take care of copying vector table, so platforms startup should do that I wonder if there is a way to change linker script in a way which will make copying of vector table automatic (by compiler dependent function). This will make platform startups a bit cleaner and will allow platform to just use __PROGRAM_START macro without any additional code to copy vector table. From what I see IAR has "initialize by copy" syntaxis so I think it may be used to tell IAR to automatically copy vector table. It is a bit more tricky with ARMClang as I have not found a way to do that there. I am not a big expert in ARMClang and IAR so maybe someone may help me here, give some directions or confirm that currently there is no way to make this idea work. Basically the intention is to simplify platform startup code and offload common operations to compiler specific platform independent functions. 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>

3 years, 11 months

2
5
0 0

FW: [Tf-openci] [Maintenance] - ci.trustedfirmware.org down time 2022-07-08

by Xinyu Zhang

Hi All, FYI. Open CI will be down from 2022-07-07 23:00 UTC to 2022-07-08 03:00 UTC for Jenkins upgrade. Please let us know if there is any problem. Thanks Xinyu -----Original Message----- From: Kelley Spoon via Tf-openci <tf-openci(a)lists.trustedfirmware.org> Sent: Wednesday, July 6, 2022 2:02 PM To: tf-openci(a)lists.trustedfirmware.org; tf-openci-triage(a)lists.trustedfirmware.org Subject: [Tf-openci] [Maintenance] - ci.trustedfirmware.org down time 2022-07-08 Hello All, The server will be offline to start a maintenance window on 2022-07-08 at 01:00 UTC. Jenkins will be put into "Shutdown Mode" at 2022-07-07 23:00 UTC to stop accepting new jobs and allow executing tasks to complete. This downtime is required to execute an upgrade to Jenkins 2.332.3. The upgrade will address several security advisories for Jenkins core and its plugins and will also bring the server to feature parity with staging. Emails will be sent prior to and following the upgrade to provide status reports. Start: 2022 07-08 01:00 UTC End: 2022-07-08 03:00 UTC Regards, -- Kelley Spoon <kelley.spoon(a)linaro.org> -- Tf-openci mailing list -- tf-openci(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-leave(a)lists.trustedfirmware.org

3 years, 11 months

1
0
0 0

Ask for review on TF-M memory check interface update patch

by Summer Qin

Hi, I have sorted out memory check functions and done some refinement. As it covers all the platforms, may I ask for a review on these patches<https://review.trustedfirmware.org/q/topic:%22memory-check-interface-update…>? I would like to merge it by 30th of this month if possible. Thanks so much! Best Regards, Summer

3 years, 11 months

1
0
0 0

PS partition dependencies

by Chris.Brand＠infineon.com

I'm experimenting with a build with the SFN backend, and I've hit an error. cmake -S . -B build_musca_sse200_GNUARM_Release -DTFM_PLATFORM=arm/musca_b1/sse_200 -DCONFIG_TFM_SPM_BACKEND=SFN -DTFM_PARTITION_PLATFORM=OFF -DTFM_PARTITION_FIRMWARE_UPDATE=OFF -DPS_ROLLBACK_PROTECTION=OFF cmake --build build_musca_sse200_GNUARM_Release results in .../build_musca_sse200_GNUARM_Release/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.c:85:9: error: 'TFM_SP_PLATFORM_NV_COUNTER_SID' undeclared here (not in a function); did you mean 'TFM_SP_NON_SECURE_ID'? TFM_SP_PLATFORM_NV_COUNTER_SID, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TFM_SP_NON_SECURE_ID Config/check_config.cmake line 93 is tfm_invalid_config((TFM_PARTITION_PROTECTED_STORAGE AND PS_ROLLBACK_PROTECTION) AND NOT TFM_PARTITION_PLATFORM) but secure_fw/partitions/protected_storage/tfm_protected_storage.yaml lists TFM_SP_PLATFORM_NV_COUNTER as a dependency unconditionally. The easy fix is to change check_config.cmake to have the PS partition unconditionally require the platform partition, but it seems that the intent is that it should still be possible to enable PS without rollback protection. Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> 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.

3 years, 11 months

2
1
0 0

Ask for review on TF-M patch

by Sherry Zhang

Hi, I have created a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15313/> which removes the unnecessary heap(including the RAM memory reserved for heap and the heap related symbols). As it covers all the platforms and compilers, may I ask for a review on this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15313/>? This patch saves about 680 bytes Flash while 4200 bytes RAM. I would like to merge it by 29th this month if possible. Thanks so much! Regards, Sherry Zhang

3 years, 11 months

1
0
0 0

Technical Forum call - June 23 - agenda

by Anton Komlev

Hello, the agenda for the forum tomorrow, June 23, 7:00-8:00 UTC 1. Proposal of External Trusted Secure Storage by Poppy Wu 2. Long Time Support (LTS) in TF-M project: the needs, cadence, scope. Open discussion. 3. AOB 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/ Thanks, Anton

3 years, 11 months

1
0
0 0

Technical Forum call - June 23

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, June 23, 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 years, 11 months

1
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M