- TF-M - lists.trustedfirmware.org

Re: Inquiry on Overriding ITS Parameters in TF-M via Zephyr

by Jain, Saurabh

Hi Anton Thank you for your response. Let me break it down a bit. 1. We have several subsystems running on the non-secure side that require certain sensitive metadata to be stored in ITS. 2. Default values of ITS parameters are insufficient. 3. While building the Zephyr app with TF-M, NS-side (during build) passes these overriding values to CMake, which adds the specified preprocessor definitions to the compiler flags of TF-M, ensuring they are available during compilation. 4. Zephyr already has the harness for this flow. This entire flow currently doesn’t work if we don’t explicitly use these preprocessors in TF-M CMake files. Using a custom profile is not feasible for us because the overriding values are provided by the NS side based on their specific needs. Additionally, even when we attempt to provide these parameters through the command line while building only TF-M (without NS-side), we encounter the same warning: "Manually-specified variables were not used by the project." This warning indicates that these parameters are not being utilized in the CMake scripts (which make sense). I guess the question would be is there a way to override these parameters from command-line, while being platform agnostic? If not, is there any specific reason we chose not to, other than this approach could potentially override the platform specific configuration, like you suggested? We would appreciate any guidance or suggestions on how to properly handle this scenario. If needed, we can discuss this further in the next TF-M Tech forum, like you suggested. Regards Saurabh On 1/24/25, 12:47 PM, "Anton Komlev via TF-M" <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi Saurabh, If I understand you correctly, you're looking to modify the ITS_MAX_ASSET definition, which is a build-time option and cannot be changed post S-side build. Could you please explain your scenario for wanting to update it from the NS-side? You're correct that a platform can redefine certain options which is intended behavior, allowing platforms to either override or verify these settings. For more details, you can refer to the TF-M configuration priorities here: https://trustedfirmware-m.readthedocs.io/en/latest/configuration/index.html… <https://trustedfirmware-m.readthedocs.io/en/latest/configuration/index.html…>. The highest priority is the command line, which can override options even those defined in platforms. We should proceed cautiously with this approach, as there might be reasons why platforms alter the default configuration. A recommended alternative is to create a custom profile and place all your options there, though some platforms might still overwrite them as expected. We can discuss this further in the next TF-M Tech forum if you wish. Hope that helps, Anton -----Original Message----- From: Jain, Saurabh via TF-M <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org>> Sent: Thursday, January 23, 2025 7:47 PM To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Inquiry on Overriding ITS Parameters in TF-M via Zephyr Hi All, We are developing a platform using TF-M with Zephyr running on the Non-Secure (NS) side. As part of our requirements, we need to override certain ITS-related parameters, such as ITS_MAX_ASSET, from the NS side. Zephyr provides a mechanism for this through Kconfig.tfm under modules/trusted-firmware-m, which includes symbols like TFM_ITS_MAX_ASSET_SIZE_OVERRIDE. When enabled, these configurations are passed to the TF-M build system via TFM_CMAKE_ARGS through CMake under modules/trusted-firmware-m. However, we observe that TF-M does not seem to support external overrides for these parameters. This results in the CMake warning: "Manually-specified variables were not used by the project." As a result, the overrides are ignored. Currently, we address this by explicitly checking for external definitions of ITS_MAX_ASSET in platform-specific TF-M CMake files. While this works, it is platform-specific. We would like to confirm: 1. Is there an existing platform-independent method to achieve such overrides that we may have missed? 2. If not, would the community be open to adding support for this functionality so it can be upstreamed and benefit other platforms? Looking forward to your input. Best regards, Saurabh -- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org <mailto:tf-m-leave@lists.trustedfirmware.org> -- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org <mailto:tf-m-leave@lists.trustedfirmware.org>

10 months, 3 weeks

2
1
0 0

Inquiry on Overriding ITS Parameters in TF-M via Zephyr

by Jain, Saurabh

Hi All, We are developing a platform using TF-M with Zephyr running on the Non-Secure (NS) side. As part of our requirements, we need to override certain ITS-related parameters, such as ITS_MAX_ASSET, from the NS side. Zephyr provides a mechanism for this through Kconfig.tfm under modules/trusted-firmware-m, which includes symbols like TFM_ITS_MAX_ASSET_SIZE_OVERRIDE. When enabled, these configurations are passed to the TF-M build system via TFM_CMAKE_ARGS through CMake under modules/trusted-firmware-m. However, we observe that TF-M does not seem to support external overrides for these parameters. This results in the CMake warning: "Manually-specified variables were not used by the project." As a result, the overrides are ignored. Currently, we address this by explicitly checking for external definitions of ITS_MAX_ASSET in platform-specific TF-M CMake files. While this works, it is platform-specific. We would like to confirm: 1. Is there an existing platform-independent method to achieve such overrides that we may have missed? 2. If not, would the community be open to adding support for this functionality so it can be upstreamed and benefit other platforms? Looking forward to your input. Best regards, Saurabh

10 months, 3 weeks

2
1
0 0

New Clang/LLVM Toolchain Support Announcement

by Anton Komlev

Hello, I am thrilled to announce the support of new Clan/LLVM toolchain, freely available here: https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm. This extends a suite of powerful tools designed to enhance your development experience and boost productivity. Key Features: * Offers Clang frontend * Available for Linux, Windows and macOS * Builds TF-M binaries for all Arm targets * Secure side built without libc and picolib libraries, while both are available to Bootloader and Non-Secure side Important notes: * Floating point support is not verified * MVE is not supported yet * This has been verified with version v18.1.3 of the toolchain. We're excited for you to try out the new toolchain support and look forward to your feedback. The use of the toolchain_CLANG.cmake is the same as all other toolchains. I plan to present the new toolchain and compare it with the existing tools in one of the upcoming TF-M forums. Meanwhile I encourage the platform owners to include the new toolchain support using arm platforms as a reference. The relevant changes are in this chain: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34351 There is ongoing discussion on the best name for the toolchain to avoid possible confusion. Should it be Clang as now, LLVM, or even LLVMClang? Please share your opinion. Thanks, and best regards, Anton.

11 months

1
0
0 0

Slow PSA Protected Storage (PS) API write operations

by Ylinen, Juha

Hi Everyone, During our investigation into the slow write operations of the PSA Protected Storage (PS) API, we identified that numerous (>10) flash erase calls occur when executing psa_ps_set() or psa_ps_remove(). A significant portion of these erase calls is linked to the rollback protection mechanism, specifically for updating Non-Volatile (NV) counters. A potential improvement we are considering is to differentiate rollback protection requirements based on the type of flash memory being used. * For systems utilizing internal flash, we suggest possibility to disable rollback protection when encryption is enabled. This improves speed of write and remove operations and reduces the flash wear. * Rollback protection should be enabled when protected storage is located in external flash to ensure data integrity and security Currently, there is a Kconfig option, CONFIG_TFM_PS_ROLLBACK_PROTECTION, to disable rollback protection. However, a build-time check requires that PS encryption is also disabled, as referenced here: https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git… To better align rollback protection with the type of flash memory, there is the possibility of updating the macro rule. This could involve either removing the existing rollback protection check or adding a new rule based on the flash type, enforcing rollback protection only for external flash. While introducing a Kconfig option for the flash memory type is a potential solution, it raises concerns about reduced security in cases of misconfiguration. Your insights on how to address this would be invaluable. Thank you in advance for your input! Best regards, Juha Ylinen

11 months, 1 week

1
0
0 0

MPU driver in beta version

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

11 months, 1 week

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

11 months, 2 weeks

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.

11 months, 2 weeks

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.

11 months, 4 weeks

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.

12 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

2
10
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M