- TF-M - lists.trustedfirmware.org

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

3 years

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 years

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 years

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

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

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 month

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

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 month

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

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

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 month

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

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

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

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M