- TF-M - lists.trustedfirmware.org

by Zhang, Hao

Hi TF-M community, I find the arm provided a mpu driver https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/main/platform…, however, it is in beta version. I am wondering anyone in the mailing list might know if the driver is intended to be finailized. Best regards, Hao

1 year, 2 months

2
2
0 0

[RFC] Add a RPC callback to identify mailbox IRQ source

by David Hu

Hi all, When TF-M RPC callbacks were introduced to support multi-core mailbox handling, typically only a single mailbox interrupt source was available on a multi-core system. Therefore, in the initial design, RPC callback handle_req(void) doesn't pass any information of mailbox interrupt source to platform mailbox drivers. Recently, some platforms, such as RSE based ones, consists of multiple mailbox interrupt sources. I notice that those platforms fetch and parse mailbox messages in their mailbox IRQ handlers. It can take quite a long time in IRQ handlers and doesn't get full benefits from Second-Level Interrupt Handling. Due to the limitation of RPC callback handle_req(void), those platforms are unable to move mailbox message handling to threaded NS Agent Mailbox SP context. I'd propose to add a new RPC callback handle_req_irq_src(irq_src) to pass mailbox interrupt source information to platform drivers. With this information, platform drivers can identify the source and select the corresponding handler to fetch, parse and dispatch mailbox messages in NS Agent Mailbox SP context, instead of in IRQ handlers. If platform owners are all satisfied with this new RPC callback, I also wonder if it can replace the existing handle_req() in future, assumed no backward compatible issues are raised. Please can you review the patches: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34317/1? Any comment is welcome. Thank you. Best regards, David Hu

1 year, 2 months

1
0
0 0

Hybrid Platform NSPE (Solution.2)

by Nicola Mazzucato

Hi All, I pushed for initial testing and review a series of patches to support the Scheduling-NSPE Hybrid Platform Solution (aka Solution-2). A "Hybrid Platform" is an extension of the MULTICORE case where applications also run in the NS-side of the core that hosts TF-M SPE. Patches can be found at this gerrit topic (hybrid-plat-nspe): https://review.trustedfirmware.org/q/topic:%22hybrid-plat-nspe%22. All the patches are Request-For-Comments (RFC) and the community is welcome to provide feedback on such changes/proposal. The "Hybrid Platform" support coming to TF-M has been discussed a few times in the past and slides and recordings are available in the technical forum past events: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/. This presented solution follows the main ideas presented in the past. However, since the last presentations, some adjustments have been done, in particular around: - naming: we won't use numbers for solutions, like Sol.1, 2 etc, but instead we name them: _SPE, _NSPE etc, to make immediately clear the use-case. - "simple first" approach: we aim to provide a "simple" solution in the attempt to provide an initial reference and keep the core code readable, compact and testable. If there are significant use-cases to be included, please share your feedback and we'll find a best solution. Kindly expect some changes on these proposed patches above while I rebase, perform some other tests and need to refactor some portions. Expected timeline for Hybrid Platform Solution: - SPE-support: already merged into mainline - NSPE-support (this series above), merge within two months (end of Feb-25), provided that there will be no disruptive changes - BALANCED-support: a new set will be available around the middle of 2025 (subject to change). Many thanks in advance and happy New Year. Best regards, Nicola Nicola Mazzucato (7): [RFC 1/7] SPM: tfm_rpc: Add `process_new_msg handler` [RFC 2/7] tfm_spe_mailbox: Add `mailbox_process_new_msg` handler [RFC 3/7] ns_agent_mailbox: Add NS_AGENT_MBOX_PROCESS_NEW_MSG_SIGNAL aux service [RFC 4/7] SPM: backend_ipc: Conditionally assert MBOX signal on SCHED_TYPE [RFC 5/7] SPM: tfm_multi_core: Record and clear mailbox IRQ via multi_core API [RFC 6/7] docs: hybrid_platform: Add documentation [RFC 7/7] Config Base for Hybrid Platform Nicola Mazzucato (he/him/his) | CE-Software Group | Arm 110 Fulbourn Rd, CB1 9NJ, Cambridge UK At Arm we work flexibly and globally, if you receive this email outside of your usual working hours please do not feel that you have to respond immediately. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

1 year, 2 months

1
0
0 0

FPU S16-S31 registers

by Roman.Mazurak＠infineon.com

Hi all, We found the problem with FPU S16-S31 registers if FPU is enabled and compiler uses S16-S31 FPU registers on CM33 non-secure code with TZ agent. SPM doesn't save/restore S16-S31 registers properly nor by PendSV neither by FLIH SVC handler. I created a patch for this problem: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34202 The second problem I found is related to lazy stacking. It's possible that float point context will be stacked by MCU when FLIH is switching to/from background thread after a new boundary is applied. As result it's possible that the non-privileged code will no have access to PSP stack of suspended partition because a new MPU settings are applied. Please review a patch for this problem: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34203 Regards, Roman.

1 year, 2 months

2
2
0 0

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.

1 year, 2 months

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

1 year, 3 months

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 >

1 year, 3 months

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

1 year, 3 months

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

1 year, 3 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

1 year, 3 months

3
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M