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

by Anton Komlev

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

15 hours, 59 minutes

6
38
0 0

Technical Forum call - July 21

by Anton Komlev

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

1 week, 2 days

6
40
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

1 month, 3 weeks

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 months

3
3
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 months, 3 weeks

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

3 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

3 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 months, 2 weeks

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 months, 2 weeks

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 months, 2 weeks

1
0
0 0

2023

2022

2021

2020

2019

2018

TF-M June 2023