- TF-M - lists.trustedfirmware.org

by Ken Liu

Hello, For isolation levels > 1, partitions need to SVC for PSA APIs. To improve the efficiency of this call type, the SVC handler needs to be simplified. Currently, there are several obvious places to be improved: - Handlers in C have multiple-level function calling; - There are a couple of checks in the handler routine that can be refined. And, to take advantage of instruction TBB, the switch/case number needs to be linear - but it is not always stable hence needs to investigate if a handmade function table would be more stable. The leading patches are here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20644 Feel free to comment or reply in this thread. Thanks. /Ken

1 year, 8 months

1
0
0 0

Adjustments for SVC number assignments that impact platforms with platform-specific SVC

by Kevin Peng

Hi, We're making some adjustments for the SVC number assignments. I'd like to collect some feedbacks, especially from downstream platforms that have your own SVC handler because corresponding changes of your SVC numbers are required when these changes were accepted. Originally, The SVC numbers are categorized by their values, for example, numbers less than 0x40 are PSA API requests and numbers larger than 0x80 are for handler mode. This is not convenient for adding new SVC because it's not intuitive to find a proper value range. More importantly, it's easy to create clashes between TF-M and platform SVC by mistake as they are defined in different files. So, we propose to divide the SVC number bits into different fields for distinguishing different types of SVC. Please see here<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20644/1/secu…> for the detailed descriptions. With these changes, it's much easier to put the SVC numbers in the right range and avoid duplications after setting the bit fields to right values. Thanks, Kevin

1 year, 8 months

1
0
0 0

ITS cmake

by Quach, Brian

Is the highlighted line below correct? Or should the angle bracket be at the end like this: $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/../protected_storage> target_include_directories(tfm_psa_rot_partition_its PRIVATE $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> ${CMAKE_BINARY_DIR}/generated/secure_fw/partitions/internal_trusted_storage PUBLIC # Required for ps_object_defs.h $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>/../protected_storage ) Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 8 months

2
1
0 0

PSA Crypto platform specific extensions

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, 8 months

2
1
0 0

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, 8 months

2
3
0 0

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, 8 months

1
0
0 0

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, 8 months

2
2
0 0

[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, 8 months

1
0
0 0

s_veneers linking problem when building uboot with flags -pie

by xulu＠allwinnertech.com

Hi experts, Recently we are building uboot with s_veneers.o, and found that we can not jump to tfm. The reason is that the jump addr is wrong when compileing with -pie. The symbol "tfm_vendor_aes_encrypt_with_hardware_ssk" in s_veneers.o. $ nm ./drivers/tfm/lib/s_veneers.o | grep tfm_vendor_aes_encrypt_with_hardware_ssk 04008029 A tfm_vendor_aes_encrypt_with_hardware_ssk Building uboot without cflags -pie, and the last line shows the wrong jump addr 0xf7fc7e61 0c0401f0 <__tfm_vendor_efuse_write_veneer>: c0401f0: b401 push {r0} c0401f2: 4802 ldr r0, [pc, #8] ; (c0401fc <__tfm_vendor_efuse_write_veneer+0xc>) c0401f4: 46fc mov ip, pc c0401f6: 4484 add ip, r0 c0401f8: bc01 pop {r0} c0401fa: 4760 bx ip c0401fc: f7fc7e61 .word 0xf7fc7e61 Building uboot without cflags -pie，and the last line shows the right jump addr 0x04008029. 0c040200 <__tfm_vendor_aes_encrypt_with_hardware_ssk_veneer>: c040200: b401 push {r0} c040202: 4802 ldr r0, [pc, #8] ; (c04020c <__tfm_vendor_aes_encrypt_with_hardware_ssk_veneer+0xc>) c040204: 4684 mov ip, r0 c040206: bc01 pop {r0} c040208: 4760 bx ip c04020a: bf00 nop c04020c: 04008029 .word 0x04008029 The linker flag -pie is default enabled in uboot(for relocation feature), and we need this feature. Could you please give us some pointers, suggestions or objections about this problem, Thanks!

1 year, 8 months

2
1
0 0

Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation test

by Edward Yang

Hi Antonio, Thank you for taking the time to help confirm the function, and we've found out that this error just resulted from the incorrect initialization of 'operation' before calling PSA APIs, after fixing this bug, we also got the correct OKM. Thanks again for your support. Best Regards, Poppy Wu 吴偏偏 http://www.mxic.com.cn Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> 2023/03/23 21:58 Please respond to Antonio De Angelis <Antonio.DeAngelis(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject [TF-M] Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation test Hi, I have tried the example below on mbed TLS running on an x86 Linux based host machine, and on the AN521 platform, and in both cases I can get consistent results, i.e. the value of the okm buffer at the end is: 0x3c, 0xb2, 0x5f, 0x25, 0xfa, 0xac, 0xd5, 0x7a, 0x90, 0x43, 0x4f, 0x64, 0xd0, 0x36, 0x2f, 0x2a, 0x2d, 0x2d, 0x0a, 0x90, 0xcf, 0x1a, 0x5a, 0x4c, 0x5d, 0xb0, 0x2d, 0x56, 0xec, 0xc4, 0xc5, 0xbf, 0x34, 0x00, 0x72, 0x08, 0xd5, 0xb8, 0x87, 0x18, 0x58, 0x65 Which I believe matches the expected output below. Given that your issue seems to be specific to the stm32l562e_dk platform, which uses its own crypto accelerator I believe rather than pure software implementation, I would suggest to have a look at the intermediate steps and compare your results against the AN521 platform results. You might want to raise this behaviour to the platform maintainer, as at this stage this seems to me to be a platform specific issue. I can only confirm that you are not misusing the PSA Crypto APIs here. Let me know if I can be of any more help. Thanks, Antonio From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, March 23, 2023 12:51 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Re: Please help check the failure of PSA_ALG_HKDF_EXPAND operation test I am going to have a look into this. Thanks for the instructions on how to reproduce. Might get a while to reply, please bear with me. Thanks, Antonio From: Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, March 23, 2023 01:36 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Please help check the failure of PSA_ALG_HKDF_EXPAND operation test Hi experts, Recently we're testing the HKDF-EXPAND interface with TF-M v1.7.0 on stm32l562e_dk platform. But the HKDF-EXPAND output didn't match the expected OKM. The test vector is as below: ALG : PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256), "info" : decode_hex("f0f1f2f3f4f5f6f7f8f9"), "L" : 42, "PRK" : "077709362c2e32df0ddc3f0dc47bba6390b6c73bb50f9c3122ec844ad7c2b3e5" "OKM" : "3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865" The corresponding code is as follow： int8_t okm[42]={0}; uint8_t info[] = {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9}; uint8_t ikm[]= { 0x7,0x77,0x9,0x36,0x2c,0x2e,0x32,0xdf, 0xd,0xdc,0x3f,0xd,0xc4,0x7b,0xba,0x63, 0x90,0xb6,0xc7,0x3b,0xb5,0xf,0x9c,0x31, 0x22,0xec,0x84,0x4a,0xd7,0xc2,0xb3,0xe5 }; status = psa_key_derivation_setup(&operation, PSA_ALG_HKDF_EXPAND(PSA_ALG_SHA_256)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_SECRET, ikm, sizeof(ikm)); status = psa_key_derivation_input_bytes(&operation, PSA_KEY_DERIVATION_INPUT_INFO, info, sizeof(info)); status = psa_key_derivation_output_bytes( &operation, okm, sizeof(okm) ); The actual output okm is : 5a 1c ea 2d 24 ee 79 c5 bf ce 27 7b ... be b 3b 2e 19 18 77 ae, which didn't match the OKM of above test vector. Have we misused the HKDF-EXPAND operation? Best Regards, Poppy Wu 吴偏偏 http://www.mxic.com.cn -- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org

1 year, 9 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M