TF-M April 2023

tf-m@lists.trustedfirmware.org

10 participants
15 discussions

by Roman.Mazurak＠infineon.com

Hello everyone, I need to extend PSA Crypto API by adding a platform specific encryption algorithm/key attribute. For example a vendor specific algorithm named ABC must be added. So, I need that following macro must be included when psa/crypto.h is included. #define PSA_ALG_ABC ((psa_algorithm_t) 0x08000123) TF-M provides PSA Crypto interface through includes located in interface/include/psa/crypto*.h. It means that we need to extend TF-M by allowing platform to provide some platform specific crypto header that will be installed in interface folder and included by psa/crypto.h. 1. Is there any activity related to this problem? 2. I'm considering to create a new crypto_config.h that must be generated during build process and which can optionally provide a macro TFM_PLATFORM_CRYPTO_EXTRA. These macro will be used in psa/crypto.h to conditionally include crypto_platform.h - header provided by platform. Thanks, Roman.

1 year

Start of TF-M v1.8.0 release

by Anton Komlev

Hello, The branch release/1.8.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=release/…> has been created indicating the start of the release process and features freeze. RC1 tag will follow after a successful run of the basic tests. Let me remind that the code is not frozen, and development can be continued on the main branch as described in TF-M Release Process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Thanks, Anton

1 year

Request for Review: Add platform specific default UART configurations

by Andersson, Joakim

Hi. We at Nordic are running the TF-M regression and PSA architecture tests on our boards, and we get occasional issues with test output because HW flow control is by default disabled in CMSIS. To enable HW flow control in the TF-M we must change the call to the CMSIS UART driver. I've created a change to allows the platform to set any non-default CMSIS configuration, such as HW flow control: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20374 I'd like to ask all platform maintainers to review this change. This change must add another define to all supported platforms, the change itself should not cause any difference in actual behavior. This can be used for other non-default UART configuration in other platforms as well. -Joakim Andersson

1 year

Support of MCUBOOT_IMAGE_NUMBER > 2

by Bohdan.Hunko＠infineon.com

Hi all, PSA FWU API update to version 1.0 made it easy to support updates of more than 2 images. To do so platform may define its own FWU_DEVICE_CONFIG_FILE which will contain definitions for all the components. So it looks like in current implementation FWU service should easily support FWU_COMPONENT_NUMBER > 2 (for example FWU_COMPONENT_NUMBER = 4) The only place that I see that doesn't support this is secure_fw/partitions/firmware_update/bootloader/mcuboot/tfm_mcuboot_fwu.c file which have following code: #if (MCUBOOT_IMAGE_NUMBER == 1) #define MAX_IMAGE_INFO_LENGTH (sizeof(struct image_version) + \ SHARED_DATA_ENTRY_HEADER_SIZE) #else #define MAX_IMAGE_INFO_LENGTH 2 * (sizeof(struct image_version) + \ SHARED_DATA_ENTRY_HEADER_SIZE) #endif So if MCUBOOT_IMAGE_NUMBER is 4 then MAX_IMAGE_INFO_LENGTH will only account for 2 images. To fix this I propose to change the code to: #define MAX_IMAGE_INFO_LENGTH MCUBOOT_IMAGE_NUMBER * (sizeof(struct image_version) + \ SHARED_DATA_ENTRY_HEADER_SIZE) This change will allow platform to support update of more than 2 components (assuming that platforms implementation of bootloader supports that) So I have few questions: 1. Will such change be accepted upstream? Do you see any problems with this change?\ 2. Are there already platforms that support update of more than 2 components? 3. Are there any known problems with supporting update of more than 2 components? 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

[RFC] Updated mailbox agent API documents

by Ken Liu

Hi, The mailbox agent API was proposed before and this time more implementation details are introduced in the document: Docs: Implementation details for Mailbox Agent API (Ifec409eb) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20421> Feel free to comment, and feel free to create implementations for it - remember response to this thread before you do. Thanks. /Ken

1 year

2024

2023

2022

2021

2020

2019

2018

TF-M April 2023