- TF-M - lists.trustedfirmware.org

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

by FLOC'H Tanguy

Hello, We are facing the same compatibility break issues, during a TF-M 1.7.0 -> 2.1.0 migration. - About the problem [1] (commit ffd13c3) Is there any plan to implement a mechanism, to migrate old Protected Storage objects, to the new format? - About the problem [2] (client id). There is also a compatibility break, on keys stored in Internal Trusted Storage (ITS). A key generated from NS, with TF-M 1.7.0, can not be read anymore after TF-M 2.1.0 migration (psa_key_attributes returns PSA_ERROR_INVALID_HANDLE). Changing client_id_limit from value -0x3c000000 to -1 makes old keys available. Is there a cleaner option, to support backward compatibility with keys created with client id = -1? Best regards, T. FLOC'H ________________________________ This electronic message and its attachments are confidential and transmitted for the exclusive use of their addressee. Should you receive this message by mistake, you are not authorized to use it for any purpose whatsoever; please delete it and notify the sender at once. LACROIX reserves the right to initiate any legal proceedings against any individual and organization in case of unauthorized use, without prejudice to possible criminal sanctions. ________________________________ Ce message et ses pièces jointes sont confidentiels et exclusivement transmis à l'usage de leur destinataire. Si vous recevez ce message par erreur, vous n’êtes pas autorisés à en faire une quelconque utilisation ; merci de le détruire et d'en avertir immédiatement l'expéditeur. LACROIX se réserve le droit de poursuivre toute entité, personne physique ou morale qui en ferait un usage non autorisé, sans préjudice d'éventuelles sanctions pénales.

8 months, 2 weeks

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

8 months, 4 weeks

2
10
0 0

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

by Miika Karanki

Hi Anton and Chris, Thank you for your replies. I have TFM_NS_MANAGE_NSID set to off. That does not prevent client_id translation to happen. `tfm_nspm_get_current_client_id` seems to do translation unconditionally here: https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git…. But as said, setting client_id_limit in code to -1 helps. Maybe there could be additional configuration #define whether to do translation when TFM_NS_MANAGE_NSID is off. Transition approach to convert the old PS data format to new one on the flash when reading data in new format fails sounds reasonable assuming there's no security problems involved in retrying to read the objects using the old format after a failure. Probably not. It anyways sounds better than supporting the old one "forever". At least to me, being able to do that transition would require a bit of learning what exactly was the old and what is the new layout. If there's some material in addition to source code, I'd be happy to check that. -Miika ke 27.11.2024 klo 23.01 Chris.Brand--- via TF-M ( tf-m(a)lists.trustedfirmware.org) kirjoitti: > Hi Miika, > > > > Unfortunately there have been a couple of changes to the way that PS data > is stored in flash. I hope that we are getting better at considering > backwards compatibility. In general I think that whenever we do introduce a > change like this, we need to ensure that data stored with the old layout > can still be read by newer code. > > > > I believe the patch that you’ve identified was part of the work to make PS > encryption optional. Looking at it now, I don’t see that the layout was a > necessary part of that work. Unfortunately, we’re now in a position where > there could be PS data stored on devices in this new format, so just > reverting that part of that patch would cause other problems. > > > > The bad news is that there’s another stored format change post-v2.1.1. The > good news is that we did think about existing data and introduced a build > option to read the old format. > > > > One solution to your problem would be similar to > https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/e8d48d78c166… > - a build option to support reading the old format, with stores then using > the new format. Another option would be to introduce the 1.8.1 format as an > alternative implementation i.e. a second struct inside union ps_crypto_t > and provide the 1.8.1 code as well as the current code (this would mean > picking a storage format at build time and using it forever). > > > > Regarding the client_id. You’re correct that the client_id is used as a > kind of access control (the client_id and UID together identify the stored > object). Yes, there was a major change to the way that client_ids are used, > with the mapping being added. Do you have TFM_NS_MANAGE_NSID set to ON? I > believe that if it is set to OFF then -1 is used inside TF-M to represent > all non-secure clients, which sounds like it may be what you need. > > > > Chris >

8 months, 4 weeks

3
2
0 0

Coding style update

by Antonio De Angelis

Hi all, just to point out that the coding guidelines are being updated to reflect feedback received over the years about the point of variable declaration. The majority of the code already follows this style, changing the guidelines to avoid further confusion. …/coding_guide.rst · Gerrit Code Review<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/33807/1/docs…> Please let us know if any feedback. Thanks, Antonio

8 months, 4 weeks

1
0
0 0

mbedtls 2.25 and 3.6

by Michael Khoyilar

Hi Team I am investigating the move from MbedTLS 2.25 to 3.6, however, our client uses the 2.25 currently (looks like they prefer to stay with it) and I need to provide convincing proof to move to 3.6 considering the upgrade issues that might arise. Any suggestions here that is convincing proof to do the migration to 3.6? I would appreciate your comments. Thanks Michael

9 months

2
1
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

9 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

9 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

9 months, 1 week

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>

9 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

9 months, 2 weeks

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M