- TF-M - lists.trustedfirmware.org

Re: [TF-M] f58bd227, Build: Disable RAM FS by default, breaks Musca_A builds

by Thomas Törnblom

Build steps: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\configs\ConfigRegressionIPC.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=GNUARM -DCMAKE_BUILD_TYPE=Debug PS C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\cmake_build_gcc> ..\flash_musca.bat C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\cmake_build_gcc>srec_cat bl2/ext/mcuboot/mcuboot.bin -Binary -offset 0x200000 tfm_sign.bin -Binary -offset 0x220000 -o tfm.hex -Intel C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\cmake_build_gcc>xcopy tfm.hex g: C:tfm.hex --- terminal output: Adding "-DPS_RAM_FS=ON -DITS_RAM_FS=ON" to the cmake line makes it work again, but I assume that should not be needed. Thomas Den 2020-06-29 kl. 18:58, skrev Thomas Törnblom via TF-M: > I’ve tried with GNUARM, ARMCLANG and IARARM on Win 10. > > I builds fine, but the boot appears to get stuck when starting the > secure image. > > I can provide the exact terminal output tomorrow. > > Thomas > > *Thomas Törnblom*, /Product Engineer/ > IAR Systems AB > Box 23051, Strandbodgatan 1 <x-apple-data-detectors://6/1> > SE-750 23 Uppsala, SWEDEN <x-apple-data-detectors://6/1> > Mobile: +46 76 180 17 80 <tel:+46%2076%20180%2017%2080> Fax: +46 18 16 > 78 01 <tel:+46%2018%2016%2078%2001> > E-mail: thomas.tornblom(a)iar.com > <mailto:thomas.tornblom@iar.com> Website: www.iar.com > <http://www.iar.com/> > Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> > >> 29 juni 2020 kl. 18:02 skrev Jamie Fox <Jamie.Fox(a)arm.com>: >> >> >> >> Hi Thomas, >> >> This is not expected. Please can you share the error that you see? >> (Might be best to open an issue on developer.trustedfirmware.org for it) >> >> Kind regards, >> >> Jamie >> >> *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of >> *Thomas Törnblom via TF-M >> *Sent:* 29 June 2020 16:38 >> *To:* tf-m(a)lists.trustedfirmware.org >> *Subject:* [TF-M] f58bd227, Build: Disable RAM FS by default, breaks >> Musca_A builds >> >> Looks like f58bd227 breaks Musca_A builds, or at least it will not >> boot without additional configuration options. >> >> Is this expected? >> >> Thomas >> >> -- >> >> *Thomas Törnblom*, /Product Engineer/ >> IAR Systems AB >> Box 23051, Strandbodgatan 1 >> SE-750 23 Uppsala, SWEDEN >> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 >> E-mail: thomas.tornblom(a)iar.com >> <mailto:thomas.tornblom@iar.com>Website: www.iar.com <http://www.iar.com> >> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> >> > -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years

1
0
0 0

f58bd227, Build: Disable RAM FS by default, breaks Musca_A builds

by Thomas Törnblom

Looks like f58bd227 breaks Musca_A builds, or at least it will not boot without additional configuration options. Is this expected? Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years

1
0
0 0

Re: [TF-M] Build issues with GNUARM with 7946bdd3

by Kumar Gala

I think I found the issue in cmake/Compiler/GNUARM.cmake not handling “.exe” correctly. Try: diff --git a/cmake/Compiler/GNUARM.cmake b/cmake/Compiler/GNUARM.cmake index fc9db7a0..8fbd97bb 100644 --- a/cmake/Compiler/GNUARM.cmake +++ b/cmake/Compiler/GNUARM.cmake @@ -18,6 +18,7 @@ set(CMAKE_EXECUTABLE_SUFFIX ".axf") if(NOT DEFINED GNUARM_PREFIX) get_filename_component(__c_bin ${CMAKE_C_COMPILER} NAME) string(REPLACE "-gcc" "" GNUARM_PREFIX ${__c_bin}) + string(REPLACE ".exe" "" GNUARM_PREFIX ${GNUARM_PREFIX}) endif() Will work up a proper change if that tests out ok. - k > On Jun 26, 2020, at 7:40 AM, Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Thanks Anton, > > I worked around it with: > > git rebase 7946bdd3 --onto 7946bdd3^ > > Cheers, > Thomas > > Den 2020-06-26 kl. 14:30, skrev Anton Komlev via TF-M: >> Thanks, Thomas. >> >> Yes, it was noted right after RC1 applied. The problem affects the build (not code) on Windows platform only. >> While waiting for the fix we do continue tests using Linux build. >> A fix will be applied or the patch reverted before TF-M release or with RC2, if happen. >> >> Cheers, >> Anton >> >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M >> Sent: 26 June 2020 09:23 >> To: DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> >> Subject: [TF-M] Build issues with GNUARM with 7946bdd3 >> >> The merge of "Build: Add support for specifying GNUARM_PREFIX" appears to break GNUARM builds. >> >> [100%] Linking C static library mbedcrypto.a >> /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found >> make[5]: *** [library/mbedcrypto.a] Fel 127 >> make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 >> make[3]: *** [all] Fel 2 >> make[2]: *** [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] Fel 2 >> make[1]: *** [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 >> make: *** [all] Fel 2 >> >> Excluding this commit is a workaround. >> >> This is on Win 10. >> >> Cheers, >> Thomas >> -- >> >> Thomas Törnblom, Product Engineer >> IAR Systems AB >> Box 23051, Strandbodgatan 1 >> SE-750 23 Uppsala, SWEDEN >> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 >> E-mail: thomas.tornblom(a)iar.com Website: www.iar.com >> Twitter: www.twitter.com/iarsystems >> >> > > -- > > Thomas Törnblom, Product Engineer > IAR Systems AB > Box 23051, Strandbodgatan 1 > SE-750 23 Uppsala, SWEDEN > Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 > E-mail: thomas.tornblom(a)iar.com Website: www.iar.com > Twitter: www.twitter.com/iarsystems > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years

1
0
0 0

Re: [TF-M] Alignment issues on stack with ITS

by Jamie Fox

Hi Thomas, It is only the size of the struct that needs to be aligned to the flash program unit, so that the write size is aligned when the struct is programmed to flash. So indeed the attribute puts too strong a constraint on the compiler as it also forces it to allocate these structs at aligned addresses on the stack. The only vaguely clean, portable way I can think of aligning up the size of the struct alone is something like: struct its_file_meta_t_padded { struct its_file_meta_t file_meta; uint8_t pad[ITS_FLASH_MAX_ALIGNMENT - (sizeof(struct its_file_meta_t) % ITS_FLASH_MAX_ALIGNMENT)]; }; But that has the disadvantage of adding ITS_FLASH_MAX_ALIGNMENT to the size of the struct in the case that it is already aligned (no zero-sized arrays), as well as the extra step of accessing the nested struct each time. Would be happy to hear any alternative solutions though. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 26 June 2020 10:07 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Alignment issues on stack with ITS ITS defines a few structs with specific alignment requirements, like: struct __attribute__((__aligned__(ITS_FLASH_MAX_ALIGNMENT))) its_file_meta_t { uint32_t lblock; /*!< Logical datablock where file is * stored */ size_t data_idx; /*!< Offset in the logical data block */ size_t cur_size; /*!< Size in storage system for this # * fragment */ size_t max_size; /*!< Maximum size of this file */ uint32_t flags; /*!< Flags set when the file was created */ uint8_t id[ITS_FILE_ID_SIZE]; /*!< ID of this file */ }; This causes issues with the IAR compiler when these structs are declared as autos: static psa_status_t its_mblock_copy_remaining_block_meta( struct its_flash_fs_ctx_t *fs_ctx, uint32_t lblock) { struct its_block_meta_t block_meta; psa_status_t err; uint32_t meta_block; size_t pos; uint32_t scratch_block; size_t size; ... The IAR compiler gives these errors if the alignment is 0x10 (the stack is 8 byte aligned): struct its_block_meta_t block_meta; ^ "C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\secure_fw\partitions\internal_trusted_storage\flash_fs\its_flash_fs_mblock.c",415 Error[Ta121]: Auto variable "block_meta" cannot have a stricter alignment than the stack I assume this alignment is only required for the flash, so the alignment attributes should be set when declaring variables in the flash, not on the type. Comments? Cheers, Thomas -- Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

6 years

1
0
0 0

Re: [TF-M] Build issues with GNUARM with 7946bdd3

by Thomas Törnblom

Thanks Anton, I worked around it with: git rebase 7946bdd3 --onto 7946bdd3^ Cheers, Thomas Den 2020-06-26 kl. 14:30, skrev Anton Komlev via TF-M: > > Thanks, Thomas. > > Yes, it was noted right after RC1 applied. The problem affects the > build (not code) on Windows platform only. > > While waiting for the fix we do continue tests using Linux build. > > A fix will be applied or the patch reverted before TF-M release or > with RC2, if happen. > > Cheers, > > Anton > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Thomas Törnblom via TF-M > *Sent:* 26 June 2020 09:23 > *To:* DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> > *Subject:* [TF-M] Build issues with GNUARM with 7946bdd3 > > The merge of "Build: Add support for specifying GNUARM_PREFIX" appears > to break GNUARM builds. > > [100%] Linking C static library mbedcrypto.a > /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found > make[5]: *** [library/mbedcrypto.a] Fel 127 > make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 > make[3]: *** [all] Fel 2 > make[2]: *** > [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] > Fel 2 > make[1]: *** > [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 > make: *** [all] Fel 2 > > Excluding this commit is a workaround. > > This is on Win 10. > > Cheers, > Thomas > > -- > > *Thomas Törnblom*, /Product Engineer/ > IAR Systems AB > Box 23051, Strandbodgatan 1 > SE-750 23 Uppsala, SWEDEN > Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 > E-mail: thomas.tornblom(a)iar.com > <mailto:thomas.tornblom@iar.com>Website: www.iar.com <http://www.iar.com> > Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> > > -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years

1
0
0 0

Re: [TF-M] Build issues with GNUARM with 7946bdd3

by Anton Komlev

Thanks, Thomas. Yes, it was noted right after RC1 applied. The problem affects the build (not code) on Windows platform only. While waiting for the fix we do continue tests using Linux build. A fix will be applied or the patch reverted before TF-M release or with RC2, if happen. Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 26 June 2020 09:23 To: DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Build issues with GNUARM with 7946bdd3 The merge of "Build: Add support for specifying GNUARM_PREFIX" appears to break GNUARM builds. [100%] Linking C static library mbedcrypto.a /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found make[5]: *** [library/mbedcrypto.a] Fel 127 make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 make[3]: *** [all] Fel 2 make[2]: *** [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] Fel 2 make[1]: *** [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 make: *** [all] Fel 2 Excluding this commit is a workaround. This is on Win 10. Cheers, Thomas -- Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

6 years

1
0
0 0

Re: [TF-M] Build issues with GNUARM with 7946bdd3

by Kumar Gala

> On Jun 26, 2020, at 3:23 AM, Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > The merge of "Build: Add support for specifying GNUARM_PREFIX" appears to break GNUARM builds. > > [100%] Linking C static library mbedcrypto.a > /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found > make[5]: *** [library/mbedcrypto.a] Fel 127 > make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 > make[3]: *** [all] Fel 2 > make[2]: *** [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] Fel 2 > make[1]: *** [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 > make: *** [all] Fel 2 > > Excluding this commit is a workaround. > > This is on Win 10. > > Cheers, > Thomas Is this issue seen on any other host OS? Linux, Mac OS X? Which specific toolchain are you using? - k

6 years

2
1
0 0

Alignment issues on stack with ITS

by Thomas Törnblom

ITS defines a few structs with specific alignment requirements, like: struct __attribute__((__aligned__(ITS_FLASH_MAX_ALIGNMENT))) its_file_meta_t { uint32_t lblock; /*!< Logical datablock where file is * stored */ size_t data_idx; /*!< Offset in the logical data block */ size_t cur_size; /*!< Size in storage system for this # * fragment */ size_t max_size; /*!< Maximum size of this file */ uint32_t flags; /*!< Flags set when the file was created */ uint8_t id[ITS_FILE_ID_SIZE]; /*!< ID of this file */ }; This causes issues with the IAR compiler when these structs are declared as autos: static psa_status_t its_mblock_copy_remaining_block_meta( struct its_flash_fs_ctx_t *fs_ctx, uint32_t lblock) { struct its_block_meta_t block_meta; psa_status_t err; uint32_t meta_block; size_t pos; uint32_t scratch_block; size_t size; ... The IAR compiler gives these errors if the alignment is 0x10 (the stack is 8 byte aligned): struct its_block_meta_t block_meta; ^ "C:\Users\thomasto\Projects\tf-m1\trusted-firmware-m\secure_fw\partitions\internal_trusted_storage\flash_fs\its_flash_fs_mblock.c",415 Error[Ta121]: Auto variable "block_meta" cannot have a stricter alignment than the stack I assume this alignment is only required for the flash, so the alignment attributes should be set when declaring variables in the flash, not on the type. Comments? Cheers, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years

1
0
0 0

Build issues with GNUARM with 7946bdd3

by Thomas Törnblom

The merge of "Build: Add support for specifying GNUARM_PREFIX" appears to break GNUARM builds. [100%] Linking C static library mbedcrypto.a /usr/bin/sh: CMAKE_GNUARM_AR-NOTFOUND: command not found make[5]: *** [library/mbedcrypto.a] Fel 127 make[4]: *** [library/CMakeFiles/mbedcrypto.dir/all] Fel 2 make[3]: *** [all] Fel 2 make[2]: *** [secure_fw/partitions/crypto/mbedcrypto_lib-prefix/src/mbedcrypto_lib-stamp/mbedcrypto_lib-build] Fel 2 make[1]: *** [secure_fw/partitions/crypto/CMakeFiles/mbedcrypto_lib.dir/all] Fel 2 make: *** [all] Fel 2 Excluding this commit is a workaround. This is on Win 10. Cheers, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years

1
0
0 0

Re: [TF-M] TF-M Technical Forum Agenda - June 25

by Anton Komlev

Hi, Please find the presentation materials attached for Secure functions topic. Reminder, the PSA L3 isolation design is here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4730 The best, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 25 June 2020 13:38 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum Agenda - June 25 Hello, The agenda for today's forum: * PSA Isolation (level 3) design review * Secure Function model * Any other business, if time permitted. See you soon, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: 17 June 2020 12:55 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M Technical Forum call - June 25 Hello, The next Technical Forum is planned on Thursday, June 25 at 15:00-16:00 UTC (US time zone). This is exceptional time zone change because of a public holiday in China that day. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

6 years

1
0
0 0

Re: [TF-M] TF-M Technical Forum Agenda - June 25

by Anton Komlev

Hello, The agenda for today's forum: * PSA Isolation (level 3) design review * Secure Function model * Any other business, if time permitted. See you soon, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 17 June 2020 12:55 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - June 25 Hello, The next Technical Forum is planned on Thursday, June 25 at 15:00-16:00 UTC (US time zone). This is exceptional time zone change because of a public holiday in China that day. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

6 years

1
0
0 0

Re: [TF-M] new tf-m-test repository

by Kumar Gala

Curious if the intent is that the tf-m-tests repo would eventually be optional? - k > On Jun 19, 2020, at 5:29 AM, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Following TF-M project restructuring, let me bring your attention to the new repository: tf-m-tests repo > The intention is to migrate testing related code/libraries/tools there and clean the main repository. > Patches have been made. Please be aware of the change. > At this moment it does not affect the project development but in the future to test TF-M you will need to use this tf-m-tests repo. > > Thanks, > Anton Komlev > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years

2
1
0 0

Re: [TF-M] TF-M v1.1 - Heads up

by Anton Komlev

Hi All, Both trusted-firmware-m and tf-m-tests repositories are tagged with TF-Mv1.1-RC1 tag marking the code freeze and beginning of the release candidate testing. Best regards, Anton Komlev Tech Lead of TF-M in Arm Ltd. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: 10 June 2020 18:28 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M v1.1 - Heads up Hi All, Just a heads up that TF-Mv1.1 tag is planned for middle to end of July. Code freeze of TF-M master is aimed around end of June to allow enough time for testing. Similar to TF-Mv1.0 and previous tags, v1.1 will include all TF-M changes in TF-M master available till code freeze in end of June. Availability of the tag will be notified via. this mailing list. Thanks, Shebu Technology Manager-TF-M, Arm Ltd.

6 years

1
0
0 0

Switch to the original MCUboot as default

by David Vincze

Hi everyone, I would like to inform you about that the default bootloader option in TF-M has been changed from TF-M's MCUBoot fork to the original MCUBoot by a commit that was merged a few hours ago (https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4551). Due to this you may experience that your TF-M builds are failing after a recent rebase onto master with the following error message: "Missing MCUBoot. Please clone the MCUBoot repo to directory....." . To solve this, you can choose from the following options: 1. Follow the instructions of the 'MCUBoot' section in the docs/getting_started/tfm_secure_boot.rst to clone the MCUBoot repository and fulfill this dependency. 2. Quick but rather temporary solution: Append '-DMCUBOOT_REPO=TF-M' to your CMake configuration command to use the MCUBoot fork from the TF-M repository as before. Example: cmake -G"Unix Makefiles" -DTARGET_PLATFORM=AN521 -DCOMPILER=ARMCLANG -DMCUBOOT_REPO=UPSTREAM ../ Please let me know, if you have any difficulties. Best regards, David Vincze

6 years

1
0
0 0

[RFC] PSA Isolation (level 3) design document

by Ken Liu

Hi, We have created one PSA Isolation implementation design document and now call for comments: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4730 The overall goal is to cover all isolation levels into this one document, and at current stage we take level 3 as an example. The image layout and regions are based on the assumption of the existing TF-M code base. Feel free to put comments, or post under this task: https://developer.trustedfirmware.org/T778 Thanks. /Ken

6 years

1
0
0 0

Re: [TF-M] MPU Fault Handler in the 'Test secure irq' test

by Andrej Butok

Hi Mate, Thank you for the confirmation. To avoid the limitation, I have switched the IRQ test service to PSA-RoT in our code. Should the original TFM do the same? Thank you, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M Sent: Tuesday, June 23, 2020 1:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] MPU Fault Handler in the 'Test secure irq' test Hi Andrej, Yes, this is a known limitation of the IRQ test case. Because of the limitation you mention in your mail it cannot be run in isolation levels higher than 1. This test is part of the core test positive test suite, which is (by default) is disabled in certain cases (mostly because of these limitations): CommonConfig.cmake: if (CORE_TEST) if (NOT CORE_IPC OR TFM_LVL EQUAL 1) set(CORE_TEST_POSITIVE ON) endif() set(CORE_TEST_INTERACTIVE OFF) endif() It might be a possible workaround to define the IRQ test service as a PRoT as well. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: Monday, June 22, 2020 16:45 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] MPU Fault Handler in the 'Test secure irq' test Hello, During my update to the new TFM version (after one month pause), occurs the MPU Fault Handler in the 'Test secure irq' regression test (TFM_ENABLE_IRQ_TEST is enabled). The reason is that the test partition is defined as APP_ROT (non-privileged), but the test accesses to the NS memory region (dined as Privileged by default): spm_irq_test_1_prepare_test_scenario_internal(enum irq_test_scenario_t irq_test_scenario, struct irq_test_execution_data_t *execution_data) "execution_data" points to a global structure in NS RAM area provided by the NS test. The workaround: Define the IRQ test partition as PSA_ROT (privileged). Is it OK? Is this known issue? Thanks, Andrej Butok

6 years

1
0
0 0

Re: [TF-M] MPU Fault Handler in the 'Test secure irq' test

by Mate Toth-Pal

Hi Andrej, Yes, this is a known limitation of the IRQ test case. Because of the limitation you mention in your mail it cannot be run in isolation levels higher than 1. This test is part of the core test positive test suite, which is (by default) is disabled in certain cases (mostly because of these limitations): CommonConfig.cmake: if (CORE_TEST) if (NOT CORE_IPC OR TFM_LVL EQUAL 1) set(CORE_TEST_POSITIVE ON) endif() set(CORE_TEST_INTERACTIVE OFF) endif() It might be a possible workaround to define the IRQ test service as a PRoT as well. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, June 22, 2020 16:45 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] MPU Fault Handler in the 'Test secure irq' test Hello, During my update to the new TFM version (after one month pause), occurs the MPU Fault Handler in the 'Test secure irq' regression test (TFM_ENABLE_IRQ_TEST is enabled). The reason is that the test partition is defined as APP_ROT (non-privileged), but the test accesses to the NS memory region (dined as Privileged by default): spm_irq_test_1_prepare_test_scenario_internal(enum irq_test_scenario_t irq_test_scenario, struct irq_test_execution_data_t *execution_data) "execution_data" points to a global structure in NS RAM area provided by the NS test. The workaround: Define the IRQ test partition as PSA_ROT (privileged). Is it OK? Is this known issue? Thanks, Andrej Butok

6 years

1
0
0 0

MPU Fault Handler in the 'Test secure irq' test

by Andrej Butok

Hello, During my update to the new TFM version (after one month pause), occurs the MPU Fault Handler in the 'Test secure irq' regression test (TFM_ENABLE_IRQ_TEST is enabled). The reason is that the test partition is defined as APP_ROT (non-privileged), but the test accesses to the NS memory region (dined as Privileged by default): spm_irq_test_1_prepare_test_scenario_internal(enum irq_test_scenario_t irq_test_scenario, struct irq_test_execution_data_t *execution_data) "execution_data" points to a global structure in NS RAM area provided by the NS test. The workaround: Define the IRQ test partition as PSA_ROT (privileged). Is it OK? Is this known issue? Thanks, Andrej Butok

6 years

1
0
0 0

Re: [TF-M] new tf-m-test repository

by Kevin Peng

Hi Thomas, Should be review.trustedfirmware.org/c/TF-M/tf-m-tests Just replace "trusted-firmware-m" with "tf-m-tests" in the URL you push patches for TF-M. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Monday, June 22, 2020 3:36 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] new tf-m-test repository What is the URL to push patches to this repo? I attempted to push the IAR RTX libraries but it failed. Cheers, Thomas Den 2020-06-19 kl. 12:29, skrev Anton Komlev via TF-M: Hi, Following TF-M project restructuring, let me bring your attention to the new repository: tf-m-tests repo<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/> The intention is to migrate testing related code/libraries/tools there and clean the main repository. Patches have been made. Please be aware of the change. At this moment it does not affect the project development but in the future to test TF-M you will need to use this tf-m-tests repo. Thanks, Anton Komlev -- Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

6 years

2
1
0 0

Re: [TF-M] new tf-m-test repository

by Thomas Törnblom

What is the URL to push patches to this repo? I attempted to push the IAR RTX libraries but it failed. Cheers, Thomas Den 2020-06-19 kl. 12:29, skrev Anton Komlev via TF-M: > > Hi, > > Following TF-M project restructuring, let me bring your attention to > the new repository: *tf-m-tests* repo > <https://git.trustedfirmware.org/TF-M/tf-m-tests.git/> > > The intention is to migrate testing related code/libraries/tools there > and clean the main repository. > > Patches have been made. Please be aware of the change. > > At this moment it does not affect the project development but in the > future to test TF-M you will need to use this tf-m-tests repo. > > Thanks, > > Anton Komlev > > -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years

1
0
0 0

Re: [TF-M] Ask for final review of symmetric based initial attestation design

by David Hu

Hi all, Symmetric initial attestation patches are merged. Symmetric initial attestation now is enabled in TF-M Profile Small. Thanks a lot for the review and support. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Monday, May 18, 2020 3:34 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Ask for final review of symmetric based initial attestation design Hi all, May I ask for a final round of review on symmetric initial attestation design document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3898? The document has been reviewed for a long time and received many valuable comments. Thanks a lot. If there is no further critical comment, I'd like to merge this design this Friday. Best regards, Hu Ziji

6 years

1
0
0 0

Re: [TF-M] new tf-m-test repository

by Kevin Peng

Thanks Anton. As you may have noticed, the CMSIS RTX libraries have been added to the tf-m-tests. There are also patches<https://review.trustedfirmware.org/q/topic:%22CMSIS_5_to_tfm_tests%22+(stat…> for TF-M to reference the libraries from tf-m-tests. The plan is to merge them before TF-M 1.1 release code freeze (around end of June). You would need to clone the tf-m-tests repo to build TF-M when these patches were merged. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, June 19, 2020 6:30 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] new tf-m-test repository Hi, Following TF-M project restructuring, let me bring your attention to the new repository: tf-m-tests repo<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/> The intention is to migrate testing related code/libraries/tools there and clean the main repository. Patches have been made. Please be aware of the change. At this moment it does not affect the project development but in the future to test TF-M you will need to use this tf-m-tests repo. Thanks, Anton Komlev

6 years

1
0
0 0

new tf-m-test repository

by Anton Komlev

Hi, Following TF-M project restructuring, let me bring your attention to the new repository: tf-m-tests repo<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/> The intention is to migrate testing related code/libraries/tools there and clean the main repository. Patches have been made. Please be aware of the change. At this moment it does not affect the project development but in the future to test TF-M you will need to use this tf-m-tests repo. Thanks, Anton Komlev

6 years

1
0
0 0

Documenting Release cadence and process

by Soby Mathew

Hi Everyone I have pushed the proposal for release cadence and process for here : https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4635 This mainly follows the TF-A release process. The release cadence period is set to be 4 months with a code freeze of up to 3 weeks. Best Regards Soby Mathew

6 years

1
0
0 0

Re: [TF-M] PS => AP ROT

by Jamie Fox

Hi Andrej, The PSA Storage spec (available here https://developer.arm.com/architectures/security-architectures/platform-sec…) states that the Protected Storage service should be implemented inside the Application Root of Trust. The principle is that the PSA Root of Trust should be kept as small as possible, to reduce the attack surface of the most privileged part of the system. As Protected Storage neither needs the privileges of the PSA Root of Trust nor is used by any PSA Root of Trust service, it should be implemented inside the Application Root of Trust. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 18 June 2020 09:16 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PS => AP ROT Hello, I have just notices that the TFM Protected Storage service partition has been changed from PSA ROT to APP ROT. Just curious, what is a reason? May it stay PSA ROT? Thank you in advance, Andrej Butok

6 years

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M