- TF-M - lists.trustedfirmware.org

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>

1 year, 4 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

1 year, 4 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

1 year, 4 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

1 year, 4 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

1 year, 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

1 year, 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

1 year, 5 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

1 year, 5 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

1 year, 5 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]

1 year, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M