- TF-M - lists.trustedfirmware.org

by Anton Komlev

Hi Everyone, I am glad to announce the new maintainer of TF-M project: * Antonio de Angelis aka adeaarm Antonio.deAngelis(a)arm.com><mailto:Antonio.deAngelis@arm.com%3e%60> Antonio was with TF-M from the very beginning being one of the project founders. Thank you, Antonio, for agreeing to maintain the project. All the best, Anton

2 years, 3 months

1
0
0 0

Image verification by 'untrusted client'

by Tomasz Jastrzębski

Is TFM-M currently able to verify the signature of the image downloaded by the 'untrusted client'? I mean, are there needed methods exposed to 'untrusted app'? If so, what methods need to be used? Kind regards, Tomasz

2 years, 3 months

1
0
0 0

tf-m main branch (latest commit) compiler error ,when build regression_test for corstone300/an547

by jidong.mei＠armchina.com

Hi I encounter a compile error , with latest main branch tf-m code. Code version : "commit 66c8eada12737f5cf6818ea84739f30ca275437d (HEAD -> main, origin/main, origin/HEAD) Author: Raef Coles <raef.coles(a)arm.com>" Build targert : corstone300/an547 regression_test Build command : cmake -S spe -B build_spe -DTFM_PLATFORM=arm/mps3/corstone300/an547 -DCONFIG_TFM_SOURCE_PATH=<tf-m_path> -DTFM_TOOLCHAIN_FILE=<tf-m_path>/toolchain_GNUARM.cmake -DTEST_S=ON -DTEST_NS=ON -DCMAKE_BUILD_TYPE=Debug & cmake --build build_spe -- install (these command fellow the build_test documentation : https://tf-m-user-guide.trustedfirmware.org/building/tests_build_instructio…) Compile error : "trusted-firmware-m/platform/ext/target/arm/mps3/corstone300/an547/cmsis_drivers/Driver_Flash.c:23:10: fatal error: tfm_hal_device_header.h: No such file or directory #include "tfm_hal_device_header.h" " Could you help to fix this issue. B,R Jidong

2 years, 3 months

3
2
0 0

ITS encryption

by Quach, Brian

Hi, It appears that ITS encryption would be required for PSA Certified Level 3. I'm seeing that this would required a platform specific HAL implementation. Is there some reason PSA Crypto APIs were not used like they were for attestation? Encryption in ITS ================= The ITS can optionally be configured to encrypt the internal trusted storage data. To support encryption in ITS the target platform must provide an implementation of the APIs defined in ``platform/include/tfm_hal_its_encryption.h``:: enum tfm_hal_status_t tfm_hal_its_aead_generate_nonce(uint8_t *nonce, const size_t nonce_size); enum tfm_hal_status_t tfm_hal_its_aead_encrypt( struct tfm_hal_its_auth_crypt_ctx *ctx, const uint8_t *plaintext, const size_t plaintext_size, uint8_t *ciphertext, const size_t ciphertext_size, uint8_t *tag, const size_t tag_size); enum tfm_hal_status_t tfm_hal_its_aead_decrypt( struct tfm_hal_its_auth_crypt_ctx *ctx, const uint8_t *ciphertext, const size_t ciphertext_size, uint8_t *tag, const size_t tag_size, uint8_t *plaintext, const size_t plaintext_size); 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
5
0 0

Build without re-downloading packages?

by Tomasz Jastrzębski

Hi All, Since ST platform seems to be supported only passively, I try to adapt tf-m for the new ST U5Axx and U5Gxx MPUs with 4MB flash on my own. It does not come easy since some things are hardcoded and new HAL version is required while breaking HAL changes have been introduced, but this is not the reason why I make this post. Is there any easy way, I mean, some cmake switch, which would allow for a full rebuild without redownloading the required packages? Since clean rebuild from scratch takes time and I need to do it frequently while my Internet connection currently is not super-fast and stable such option would be the most helpful. Kind regards, Tomasz

2 years, 4 months

2
1
0 0

Re: Attest token v2.0 in psa-arch-tests

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

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

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

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

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

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

2 years, 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]

2 years, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M