- TF-M - lists.trustedfirmware.org

by Zhang, Hao

Hi TF-M community, TF-M allows Semiconductor vendors to plug in their HW accelerator using PSA cryptoprocessor driver interface. I have a couple of questions in terms of the driver interface. 1. To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS using driver interface, for the multipart operation, https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa… states that "A driver that implements a multi-part operation must define all of the entry points in this family as well as a type that represents the operation context." Take aead encrypt as an example, if the underlying hardware does not support aead_abort, could it implements aead_abort by simply return PSA_ERROR_NOT_SUPPORTED? 2. The driver interface depends heavily on psa_crypto_driver_wrappers.h to dispatch operations to customized HW accelerator, where the psa_crypto_driver_wrappers.h file is automatically generated by scripts/data_files/driver_templates/psa_crypto_driver_wrappers.h.jinja. To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS, would the approach be creating a customized psa_crypto_driver_wrappers.h.jinja file, the driver description file in JSON, and entry point functions. If so and we are considering upstreaming TF-M in the future, all these files would go inside platform/ext/accelerator/<vendor name>. Efforts need to be made so files such as psa_crypto_driver_wrappers.h.jinja should point to mbedtls, right? Additionally, as .jinja is retiring (mentioned in another email exchange), how would semi vendors update psa_crypto_driver_wrappers.h in the future? [https://opengraph.githubassets.com/c87e79773a7fb0841ea038f7cf3dfdf4170debb8…]<https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa…> mbedtls/docs/proposed/psa-driver-interface.md at zephyr · zephyrproject-rtos/mbedtls<https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa…> mbedtls module for Zephyr, this is not a mirror of the official mbedtls repository. - zephyrproject-rtos/mbedtls github.com Thank you very much! Best regards

1 year, 2 months

4
9
0 0

Firmware Update: Storage Failure While Rejecting a Staged Image

by cedric.klikpo＠scalinx.com

Hi, I encounter a storage failure when trying to reject a staged image. I get this error by executing `tfm_fwu_test_common_001` in `fwu_tests_common.c`. The error occurs when the `erase_boot_magic` function attempts to erase the magic number in the image trailer by writing erase into it. The reason I am writing this post is to ask: 1. If the `erase_boot_magic` failure is a known bug in the firmware update, is a fix planned or existing? 2. Why doesn't the `erase_boot_magic` function erase the sector where the magic number is located in the image trailer, considering we erasing in a flash? Thanks! Best regards, Cedric

1 year, 2 months

1
0
0 0

Remove 'tfm_api_ns_tz' and 'tfm_api_ns_mailbox' targets

by Anton Komlev

Hello, I want to bring community attention to a bug fix in build script for NS application: In the original design we shall have a single CMake target 'tfm_api_ns' prepared and exported by SPE for building NSPE with consistent configuration. At some moment 2 extra targets 'tfm_api_ns_tz' and 'tfm_api_ns_mailbox' were introduced for different S-NS communication methods to be linked to tfm_api_ns on NS side. This created unnecessary NS dependency on SPE configuration and disallows creating NS application working with all platforms. This patch is fixing the issue: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/29005 Ideally, we should remove these redundant targets but that will break projects already adjusted and using them. There are 2 approaches to address the issue: 1. Preferred. Remove the targets and ask dependent projects for adjustment. (effectively, is 1 line change to stop linking to them). 2. Keep those targets as empty dummies for compatibility, polluting the code. Please comment and object the removal (approach 1) if it's critical for your project. I would appreciate your feedback within 2 weeks to make the right decision. Thanks, Anton

1 year, 3 months

1
0
0 0

help - error in regression.sh using STM Nucleo-L552ZE-Q

by Miguel Costa

Hello, I followed this tutorial to add an example secure partition in TF-M ( https://tf-m-user-guide.trustedfirmware.org/integration_guide/services/tfm_… ) and then followed these instructions to flash the application to my Nucleo-L552ZE-Q board ( https://tf-m-user-guide.trustedfirmware.org/platform/stm/common/stm32l5xx/r… ). However, the script regression.sh returned the error: Error: Cannot connect to access port 0! If you are trying to connect to a device with TrustZone enabled please try to connect with HotPlug mode. If you are trying to connect to a device which supports Debug Authentication with certificate or password, please open your device using it. After this, I am unable to connect my board STM32Cube Programmer or to flash any application using Keil MDK ARM, CubeIDE, etc. The same error is returned every time. Before I runned the regression.sh script, the board was working as expected and I was able to flash simple applications (non using TF-M) to the board. I've already tried to connect the board to the STM32Cube Programmer using the Hot Plug mode - (i) pulled BOOT0 pin to HIGH, (ii) connected the board to the PC, (iii) selected Hot Plug mode in STM32Cube Programmer and Hit Connect - but did not work. I get this log: [cid:20937ade-7ed2-4beb-bced-d577c3e58dd3]

1 year, 3 months

1
0
0 0

psa_interface_thread_fn_call section

by Bohdan.Hunko＠infineon.com

Hi all, Why does TFM assigns function to psa_interface_thread_fn_call section and then never places them anywhere specific? This way functions assigned to this section are placed outside of the code region which may result in unpredictable behavior. 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>

1 year, 3 months

2
4
0 0

Re: Is cryptocell-312 now maintaining by TF-M mainly?

by Lee, William

Thanks Antonio! 😊 (fixed typo in subject, sorry ☹) Thanks, William From: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> Date: Wednesday, May 15, 2024 at 2:18 PM To: "Lee, William" <William.Lee(a)garmin.com>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: Re: Is crytocell-312 now maintaining by TF-M mainly? Yes, CryptoCell code in the TF-M repo is the only maintained repository. Thanks, Antonio Sent from Outlook for Android From: Lee, William via TF-M <tf-m@ lists. trustedfirmware. org> Sent: Wednesday, May 15, 2024 5: 32: 59 am To: tf-m@ lists. trustedfirmware. org Yes, CryptoCell code in the TF-M repo is the only maintained repository. Thanks, Antonio Sent from Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/AAb9ysg__;!!EJc4YC3iFmQ!Q29CY2id1…> ________________________________ From: Lee, William via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, May 15, 2024 5:32:59 am To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Is crytocell-312 now maintaining by TF-M mainly? Hello! I saw [1] is not updating anymore, but [2] is still active, anyone knows if [2] is the main place for cryptocell-312? Thanks! [1] https://github.com/ARM-software/cryptocell-312-runtime<https://urldefense.com/v3/__https:/github.com/ARM-software/cryptocell-312-r…> [2] https://git.trustedfirmware.org/TF-M/trusted-firmware-m/+log/refs/heads/mai…<https://urldefense.com/v3/__https:/git.trustedfirmware.org/TF-M/trusted-fir…> Thanks, William

1 year, 3 months

2
1
0 0

Is crytocell-312 now maintaining by TF-M mainly?

by Lee, William

Hello! I saw [1] is not updating anymore, but [2] is still active, anyone knows if [2] is the main place for cryptocell-312? Thanks! [1] https://github.com/ARM-software/cryptocell-312-runtime [2] https://git.trustedfirmware.org/TF-M/trusted-firmware-m/+log/refs/heads/mai… Thanks, William

1 year, 3 months

2
1
0 0

TF-M release v2.1.0 announcement

by Anton Komlev

Hello, I am happy to announce the new release of TF-M v2.1.0. New major features are: * TF-M aligns the Crypto service to the same PSA Crypto headers used by the Mbed TLS 3.6.0 reference implementation. * Initial support for on-core and off-core clients on Hybrid platforms (A-profile + M-profile or M-profile + M-profile) using solution 1. The functionality is still under active development. * P256-M component is enabled on the BL2 stage for image signature verification based on ECDSA. * MCUboot upgrade to v2.1.0. * Mbed TLS upgrade to v3.6.0. * BL2 now provides a thin PSA Crypto core layer when MCUBOOT_USE_PSA_CRYPTO=ON and can use builtin keys when ECDSA based signature verification is selected with MCUBOOT_SIGNATURE_TYPE="EC-P256". This version is the first, intended for Long Term Support (LTS) after PSA certification and tagging TF-Mv2.1.0-LTS as described in the updated Release Process. Please check the release notes 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 and TF-M team.

1 year, 3 months

1
0
0 0

Wrong Life Cycle values in iatverifier

by Bohdan.Hunko＠infineon.com

Hi I am trying to use iatverifier tool from tf-m-tools repo to verify token and it seems like the values for Security Lificycle in the tool are wrong, because: this spec https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-21.html defines them as psa-lifecycle-unknown-type = 0x0000..0x00ff psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff psa-lifecycle-secured-type = 0x3000..0x30ff psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff psa-lifecycle-decommissioned-type = 0x6000..0x60ff Which is consistent with values of tfm_security_lifecycle_t enum in TFM enum tfm_security_lifecycle_t { TFM_SLC_UNKNOWN = 0x0000u, TFM_SLC_ASSEMBLY_AND_TEST = 0x1000u, TFM_SLC_PSA_ROT_PROVISIONING = 0x2000u, TFM_SLC_SECURED = 0x3000u, TFM_SLC_NON_PSA_ROT_DEBUG = 0x4000u, TFM_SLC_RECOVERABLE_PSA_ROT_DEBUG = 0x5000u, TFM_SLC_DECOMMISSIONED = 0x6000u, TFM_SLC_MAX_VALUE = UINT32_MAX, }; But in the tf-m-tools/iat-verifier/iatverifier/psa_iot_profile1_token_claims.py these values are defined differently # Security Lifecycle claims SL_UNKNOWN = 0x1000 SL_PSA_ROT_PROVISIONING = 0x2000 SL_SECURED = 0x3000 SL_NON_PSA_ROT_DEBUG = 0x4000 SL_RECOVERABLE_PSA_ROT_DEBUG = 0x5000 SL_PSA_LIFECYCLE_DECOMMISSIONED = 0x6000 Thus I am getting SL_UNKNOWN instead of TFM_SLC_ASSEMBLY_AND_TEST Is this a known issue? Can this be fixed? 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>

1 year, 4 months

3
3
0 0

Isolation Level 2/3 IO vector access

by Quach, Brian

Hi, For Isolation Level 2, ARoT cannot access PRoT data. If PRoT partition makes a call to ARoT partition, how are the input/output buffers made accessible to the ARoT partition so a transient copy of the data can be made? I looked at the AN521 implementation of tfm_hal_activate_boundary() and it does add any MPU regions to allow unprivileged access under Isolation Level 2. For Isolation Level 3, I assume the input/output buffers would need to added to a runtime memory asset to allow unprivileged access. Is my understanding correct? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 4 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M