- TF-M - lists.trustedfirmware.org

Re: Firmware Update: Storage Failure While Rejecting a Staged Image

by Maulik Patel

Hello Cedric, I tried the FWU tests on musca b1 platform and all of them passes without any failures. Could you please provide more context on specific version/commit or platform where you encounter PSA_ERROR_STORAGE_FAILURE? Best Regards, Maulik ________________________________ From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org> Sent: 07 June 2024 1:00 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Digest, Vol 68, Issue 6 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Firmware Update: Storage Failure While Rejecting a Staged Image (cedric.klikpo(a)scalinx.com) ---------------------------------------------------------------------- Message: 1 Date: Thu, 06 Jun 2024 13:00:29 -0000 From: cedric.klikpo(a)scalinx.com Subject: [TF-M] Firmware Update: Storage Failure While Rejecting a Staged Image To: tf-m(a)lists.trustedfirmware.org Message-ID: <171767882935.438215.6657950002748011855(a)lists.trustedfirmware.org> Content-Type: text/plain; charset="utf-8" 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 ------------------------------ Subject: Digest Footer TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org ------------------------------ End of TF-M Digest, Vol 68, Issue 6 ***********************************

6 months, 1 week

2
1
0 0

API_DISPATCH for tfm_crypto_api.c

by Quach, Brian

Hi, I noticed that trusted-firmware-m\interface\src\tfm_crypto_api.c defines two API_DISPATCH macros for psa_call(). It is used most of the time in the file, but I still see ~10 instances where psa_call() is used. Can it be changed to consistently use the API_DISPATCH macros. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

6 months, 2 weeks

2
2
0 0

PSA Cryptoprocessor Driver Interface

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

6 months, 2 weeks

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

6 months, 2 weeks

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

6 months, 3 weeks

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]

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

7 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

7 months, 1 week

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

7 months, 1 week

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.

7 months, 1 week

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M