November 2024 - TF-M - lists.trustedfirmware.org

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 day, 11 hours

9
78
0 0

Technical Forum call - Sep 12 (East time zone).

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, Sep 12 at 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

1 month, 1 week

1
7
0 0

connection-based MMIOVEC

by Quach, Brian

Hi, I am trying to use connection-based (instead of SFN) Crypto service with MMIOVEC, but I noticed that iovec_status is not automatically cleared so the second psa_call causes a TFM panic due to detection of a previously mapped IOVEC. FF spec says: [cid:image001.png@01DB3B6B.1D4E93F0] In tfm_crypto_call_srv(), I see the output vecs are unmapped but not the input vectors. Should the inputs be unmapped here as well? (psa_attest_get_token also does not unmap input vecs) status = tfm_crypto_init_iovecs(msg, in_vec, in_len, out_vec, out_len); if (status != PSA_SUCCESS) { return status; } tfm_crypto_set_caller_id(msg->client_id); /* Call the dispatcher to the functions that implement the PSA Crypto API */ status = tfm_crypto_api_dispatcher(in_vec, in_len, out_vec, out_len); #if PSA_FRAMEWORK_HAS_MM_IOVEC == 1 for (i = 0; i < out_len; i++) { if (out_vec[i].base != NULL) { psa_unmap_outvec(msg->handle, i, out_vec[i].len); } } #else /* Write into the IPC framework outputs from the scratch */ for (i = 0; i < out_len; i++) { psa_write(msg->handle, i, out_vec[i].base, out_vec[i].len); } Currently, to clear the connection's iovec_status, I have to call psa_close() after every psa_call() and reconnect with psa_connect() before the next psa_call() which adds overhead. Is this behavior of not automatically clearing iovec_status for connection-based services by design? As an alternative to calling psa_unmap_invecs(), I was wondering if spm_get_connection()/spm_get_idle_connection() could be modified with the following workaround to avoid needing to close/connect: #if CONFIG_TFM_CONNECTION_BASED_SERVICE_API == 1 connection = handle_to_connection(handle); if (!connection) { return PSA_ERROR_PROGRAMMER_ERROR; } if (spm_validate_connection(connection) != PSA_SUCCESS) { return PSA_ERROR_PROGRAMMER_ERROR; } /* WORKAROUND */ #if PSA_FRAMEWORK_HAS_MM_IOVEC connection->iovec_status &= 0xFFFF0000; // Clear status of input vecs #endif /* Validate the caller id in the connection handle equals client_id. */ if (connection->msg.client_id != client_id) { return PSA_ERROR_PROGRAMMER_ERROR; } /* * It is a PROGRAMMER ERROR if the connection is currently * handling a request. */ if (connection->status != TFM_HANDLE_STATUS_IDLE) { return PSA_ERROR_PROGRAMMER_ERROR; } if (!(connection->service)) { /* FixMe: Need to implement a mechanism to resolve this failure. */ return PSA_ERROR_PROGRAMMER_ERROR; } #else Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

3 months, 4 weeks

2
10
0 0

Backwards compatibility of Protected Storage implementation (TF-M 1.8.1 -> 2.1.1)

by Miika Karanki

Hi, I am working on an update from TF-M 1.8.1 to TF-M 2.1.1 on a board that uses encrypted Protected Storage. The board used is stm32 b_u585i_iot02a, NSPE side using Zephyr OS. I want to support field updates as well for devices already having Protected Storage objects created from NSPE. In my case, Protected Storage is created and used by TF-M 1.8.1, and I want it to remain functional after upgrading to TF-M 2.1.1. PS_CRYPTO_AEAD_ALG is set to (default) PSA_ALG_GCM. I have faced two issues with the uplift: 1. It seems commit ffd13c3 ( https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/ffd13c31d5e6…) has changed the layout how Protected Storage objects are stored into flash. With TF-M 2.1.1 and old PS data, PS init fails (or gets recreated if PS_CREATE_FLASH_LAYOUT, which I don't want since then all the existing objects would get erased). If I revert the commit (and https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git… as not to have conflicts), then the PS initialization can pass and objects are decrypted successfully. I have not been able to understand this thoroughly, but at least change in `union ps_crypto_t` struct member order is changing padding (sizeof 48 -> 40), and that in turn seems to shift at least additional data by 8 bytes via `#define PS_NON_AUTH_OBJ_TABLE_SIZE sizeof(union ps_crypto_t)`. Is this compatibility issue "a bug" in 2.1.1 or expected by design? 2. PS objects in 1.8.1 were storing client id to the object table entry to implement access control (?). With 1.8.1, the client id that got stored was -1. With 2.1.1, likely due to the Mailbox NS Agent Design Update ( https://tf-m-user-guide.trustedfirmware.org/design_docs/dual-cpu/mailbox_ns…), non-secure requests to get an object seems to pass client ID -0x3c000000 to the Protected Storage implementation. That is, client id -1 seems to be transformed to `client_id_limit`. Due to this, `psa_ps_get_info()` fails to get an object that has been previously made with 1.8.1 FW. I am able to get reading of old stored objects working by changing `client_id_limit` from value -0x3c000000 to -1 which changes to use 1-to-1 mapping when using client_id=-1. But I am unsure if this change causes some unwanted side effects. Is this the correct way to gain backwards compatibility? And if it is, would it make sense to pick https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git… into 2.1.x branch and add a configuration flag for the 1-to-1 mapping support without code change for backwards compatibility? Thanks, Miika

4 months

3
2
0 0

tf-m-tests for Floating point unit

by Zhang, Hao

Hi TF-M Maintainers, I am trying to build tf-m regression tests with fpu tests on for an521 and musca_s1 (I manually enable allow fpu tests for musca_s1) from Zephyr's west build. I did that by 1. set(CONFIG_TFM_ENABLE_FP ON) in config.cmake 2. set(TEST_NS_FPU ON) in tfm_test_config.cmake But both build fails with ~/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: secure_fw/partitions/partitions/service_5/libtfm_app_rot_partition_fpu_service.a(tfm_fpu_service_test.o): in function `fpu_service_check_fp_register': ~/work/zephyrproject_adi/modules/tee/tf-m/tf-m-tests/tests_reg/test/secure_fw/suites/fpu/service/tfm_fpu_service_test.c:48: undefined reference to `dump_fp_callee' ~/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: ~/work/zephyrproject_adi/modules/tee/tf-m/tf-m-tests/tests_reg/test/secure_fw/suites/fpu/service/tfm_fpu_service_test.c:39: undefined reference to `dump_fp_callee' ~/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: ~/work/zephyrproject_adi/modules/tee/tf-m/tf-m-tests/tests_reg/test/secure_fw/suites/fpu/service/tfm_fpu_service_test.c:42: undefined reference to `populate_callee_fp_regs' ~/zephyr-sdk-0.16.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: secure_fw/partitions/partitions/service_5/libtfm_app_rot_partition_fpu_service.a(tfm_fpu_service_test.o): in function `fpu_service_check_fp_register_after_ns_inturrept': ~/work/zephyrproject_adi/modules/tee/tf-m/tf-m-tests/tests_reg/test/secure_fw/suites/fpu/service/tfm_fpu_service_test.c:92: undefined reference to `fp_func_jump_template'. I modified line 16-19 of https://github.com/zephyrproject-rtos/tf-m-tests/blob/a1a178d8c1f3c75763511… to below target_sources(tfm_app_rot_partition_fpu_service PRIVATE tfm_fpu_service_test.c ../fpu_tests_common.c ) Then, it starts building successfully. Is there anything particular I am missing. Thank you! My tf-m tests version is 502ea90105ee18f20c78f710e2ba2ded0fc0756e (Merge pull request #11 from tomi-font/update_2.1.1)for https://github.com/zephyrproject-rtos/tf-m-tests. Best regards, Hao

4 months, 1 week

2
1
0 0

FPU use with TF-M

by Jain, Saurabh

Hi We’re developing a platform using TF-M and would like to get some clarity on using FPU on Secure and Non-Secure side. The idea is to let NS application decide if it wants to use FPU. Currently, we are enabling CONFIG_TFM_ENABLE_FP which means we’re setting CPACR.CP10, CPACR.CP11 and enabling NSACR.CP10, NSACR.CP11. With this configuration: 1. Is it okay if SE perform some FP operation which would set CONTROL.FPCA and return to NSE (CPACR_NS.CP10 and CPACR_NS.CP11 are not set) while CONTROL.FPCA is still set? 2. With the above configuration, if NSE wants to use FPU, it simply needs to enable CPACR_NS.CP10 and CPACR_NS.CP11. Is this correct? 3. If SE doesn’t require FPU, we could simply enable CONFIG_TFM_ENABLE_CP10CP11 (CONFIG_TFM_ENABLE_FP is OFF) and NS app would still be able access FPU after enabling CPACR_NS bits? 4. There is a hard requirement for the -mfloat-abi to be consistent for S, NS and all the static libraries used? Thank you in advance! Best Saurabh Jain

4 months, 2 weeks

2
1
0 0

FreeRTOS OTA PAL PSA status

by Bohdan.Hunko＠infineon.com

Hi all, I have found this interesting repo repo https://github.com/Linaro/freertos-ota-pal-psa I was wondering whether this is official PSA FW UPDATE API support for FreeRTOS, and is it still supported/maintained? 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>

4 months, 2 weeks

3
3
0 0

TF-M Small Profile with Initial Attestation - Related Query

by Srinivasan, Jayashree

Hello, I have been trying to test the initial attestation feature using the regression build for a platform that we are developing. TF-M small profile has been configured, which enables symmetric key-based attestation. On running the regression tests, the TFM_NS_ATTEST_TEST_2001 testcase fails. On further debugging, I found that the static buffer that mbedtls uses for its allocation is not sufficient ( CRYPTO_ENGINE_BUF_SIZE = 0x400 in small profile). When I increase the buffer size to 0x500, the testcase passes. Therefore, I wanted to know if this change needs to be adopted upstream or if I might be overlooking something on my end. Any leads in this regard would be helpful. Thanks, Jayashree

4 months, 2 weeks

2
2
0 0

ARM PPC Driver invocation

by Michael Khoyilar

Hi Team, Thanks for you helps. This this time I want to know how does PPC functions will be called from application to set a possible feature? The question is how PPC functions are exposed to outside world? I know we have a common ARM API in under platform/ext/driver/Driver_PPC.h I am mapping my PPCs to this API, however wondering how they might be called that refer to my specific PPCs ? I am not using the ARM naming for my PPCs drivers, for example not using the name Driver_AHB_PPCEXP0 (using the name Driver_APB_PPCBASE0). Thank you again. Michael

4 months, 2 weeks

2
1
0 0

Use of ROM address - flash_layout.h

by Michael Khoyilar

Hi all, I am getting to know the TF-M, yet I do not understand the following comment and code where ROM (Read Only) is mentioned and its address used to store Code Data (flash_layout.h)!! Can someone help me understand this better? Thanks BR Michael /* Use flash memory to store Code data */ #define S_ROM_ALIAS_BASE (0x10000000) #define NS_ROM_ALIAS_BASE (0x00000000)

4 months, 4 weeks

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M November 2024