December 2023 - TF-M - lists.trustedfirmware.org

by Tamas Ban

Hi, Sorry 2nd link was broken. Here is the working version: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab… Tamas Ban From: Andersson, Joakim <Joakim.Andersson(a)nordicsemi.no> Sent: 2022. május 9., hétfő 12:14 To: Tamas Ban <Tamas.Ban(a)arm.com> Subject: RE: Attestation token new spec Is te second link broken? I get a 404 error code. -Joakim From: Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: mandag 9. mai 2022 11:31 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Attestation token new spec Hi, the initial attestation token implementation is aligned with this specification: https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-05<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack…> This spec is still evolving and there is a newer version which changes the key values of the claims in the token: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab…<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.…> This can cause combability issues between token issuer (device) and token verifier (some remote verification service). This is an ABI change between token issuer and consumer. The breaking effect would be manifest in unaccepted IAT tokens by the verifier. On-device side I see these options to make the transition: - A build-time option could be introduced which determines which range of key numbers to use. The default value would be the new range. To not let new users pick up the old values accidentally. Existing users can notice the incompatibility issue during the integration test and adjust their build command accordingly. However, the old range would be announced as deprecated in the next TF-M release, then will be removed in the next release after. - Immediate switch over to the new range, without supporting the old range anymore. On the verification service side, an SW update can handle the transition and might be accepting both ranges for a while. I assume the verification service can be updated more easily than remote devices therefore better to handle the compatibility issue there. - Keeping the support for both ranges for the long term and letting users choose by build time. Please share your thoughts on: - Are you aware that the attestation service is used in deployed devices where this transition can cause incompatibility? - From the above list which option would you vote to support the transition? Best regards, Tamas Ban

1 year

3
4
0 0

FIH volatile structure and stack usage

by Roman.Mazurak＠infineon.com

Hi all, I found that using FIH medium/high profile with gcc generates code that uses stack extensively. It happens because fih_int structure is marked as volatile. Is there any reason why structure itself is marked as volatile? Why it's not enough to make val and msk volatile members of fih_int structure? Best regards, Roman.

1 year

2
4
0 0

Redundant checks in FWU code

by Bohdan.Hunko＠infineon.com

Hi all, In config/check_config.cmake there is a following code: tfm_invalid_config((MCUBOOT_UPGRADE_STRATEGY STREQUAL " DIRECT_XIP " OR MCUBOOT_UPGRADE_STRATEGY STREQUAL "RAM_LOAD") AND TFM_PARTITION_FIRMWARE_UPDATE) So looks like FWU is not supported when DIRECT_XIP or RAM_LOAD upgrade strategies are used. But then in FWU code I see a lot of checks for DIRECT_XIP or RAM_LOAD, for example in fwu_bootloader_get_image_info: #if !defined(MCUBOOT_DIRECT_XIP) && !defined(MCUBOOT_RAM_LOAD) && \ !defined(MCUBOOT_OVERWRITE_ONLY) What is the point of these checks if it is impossible to compile FWU code with DIRECT_XIP Because of check in config/check_config.cmake? 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
5
0 0

[RFC] Bump minimum CMake version required

by David Hu

Hi all, The current minimum CMake version specified in TF-M is 3.15. It is quite out-of-date. I’d like to propose to increase minimum CMake version to 3.21. CMake 3.21 can bring in some benefits, compared to CMake 3.15 * NEW behavior of several CMake policies, such as CMP0123 for Armclang. * After build split, TF-M secure build installs several build scripts. When NS build includes those build scripts, `CMAKE_CURRENT_FUNCTION_LIST_FILE/DIR` can make it easier to handle source code paths. CMake 3.21 was released 2 years ago. It should be stable enough now. May I know if you have any feedback or different opinions? Thank you. Best regards, Hu Ziji

1 year

2
4
0 0

Reduce dependency of NS Mailbox structure on non-secure configurations

by Roman.Mazurak＠infineon.com

Hi all, I faced the problem that mailbox configuration of secure image differs from one provided for non-secure. It's because I'm using a split-build but a little bit different that is prepared for v2.0. I think we can minimize dependencies and unexpected impacts between different images when common data structures will have less customization. Currently we have three options that can change mailbox structures: 1. NUM_MAILBOX_QUEUE_SLOT - number of mailbox slots 2. TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD - defines which NS client implementation is selected. 3. TFM_MULTI_CORE_TEST - specify whether NS multi-core test suite is built. There is requirement that NUM_MAILBOX_QUEUE_SLOT must be set to 1 if NS bare metal environment is used. But this limitation is excessive. Because it's important that secure side is not using slots that are not used by non-secure side. It can be possible to use NS bare metal client even if mailbox queue size is more than one, it's just the waste of resources in such case. But it can bring a benefit that it's possible to build secure image with default settings (aka 4 mailbox slots) and there is no need to rebuild it if there will be decision to switch from RTOS to bare metal environment which can be useful for some end-user use cases. More flexible update will be to pass number of allocated slots from NS side to TF-M during initialization, it's just important to validate that number of slots doesn't not exceed maximum supported by design. TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD is another problem, because mailbox_reply_t allocates data that are not shared but used by non-secure side only. Which means that it's important to decide which NS client implementation is going to be used when TF-M is built. I see two different solutions for this problem: 1. Use union to allocate space for both of them and let decide NS client implementation which on to use. Something like this: struct mailbox_reply_t { union { //#ifdef TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD uint8_t *woken_flag; /* Indicate that owner task has been * or should be woken up, after the * reply is received. */ //#else bool is_woken; /* Indicate that owner task has been * or should be woken up, after the * reply is received. */ //#endif }; }; 1. Redesign mailbox by separating data that are used by NS client from data that are shared between cores. So, it will be much easier to update non-secure client without touching secure image. It looks like there is data needed for test suite only (nr_tx and nr_used_slots fields of ns_mailbox_queue_t) defined by TFM_MULTI_CORE_TEST. I think we can allocate it in test suite only, so there will be no need to allocate this data in shared structure and there will not be the case when location of is_full field of ns_mailbox_queue_t accessed by both cores have different location if TFM_MULTI_CORE_TEST configuration is not applied the same way for both secure and non-secure images. Regards, Roman.

1 year

3
7
0 0

FPU flags for mbedTLS targets

by Quach, Brian

Hi, /secure_fw/partitions/crypto/CMakeLists.txt is missing passing compiler flags to mbedTLS targets which would be needed for correct FPU flags. I believe the highlighted code would be the fix: target_compile_options(${MBEDTLS_TARGET_PREFIX}mbedcrypto PRIVATE ${COMPILER_CP_FLAG} $<$<C_COMPILER_ID:GNU>:-Wno-unused-const-variable> $<$<C_COMPILER_ID:GNU>:-Wno-unused-parameter> $<$<C_COMPILER_ID:ARMClang>:-Wno-unused-const-variable> $<$<C_COMPILER_ID:ARMClang>:-Wno-unused-parameter> ) target_compile_options(${MBEDTLS_TARGET_PREFIX}p256m PRIVATE ${COMPILER_CP_FLAG} ) Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year

2
5
0 0

compile error when PS_ENCRYPTION=OFF

by Quach, Brian

Hi, if I set PS_ENCRYPTION=OFF set(PS_ENCRYPTION OFF CACHE BOOL "Enable encryption for Protected Storage partition") I see this compile error: In file included from /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/tfm_internal_trusted_storage.c:32: /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:48:31: error: 'PS_TAG_LEN_BYTES' undeclared here (not in a function) 48 | #define PS_TAG_IV_LEN_MAX ((PS_TAG_LEN_BYTES > PS_IV_LEN_BYTES) ? \ | ^~~~~~~~~~~~~~~~ /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:60:20: note: in expansion of macro 'PS_TAG_IV_LEN_MAX' 60 | uint8_t tag_iv[PS_TAG_IV_LEN_MAX]; | ^~~~~~~~~~~~~~~~~ /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:48:50: error: 'PS_IV_LEN_BYTES' undeclared here (not in a function) 48 | #define PS_TAG_IV_LEN_MAX ((PS_TAG_LEN_BYTES > PS_IV_LEN_BYTES) ? \ | ^~~~~~~~~~~~~~~ /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:60:20: note: in expansion of macro 'PS_TAG_IV_LEN_MAX' 60 | uint8_t tag_iv[PS_TAG_IV_LEN_MAX]; | ^~~~~~~~~~~~~~~~~ make[7]: *** [secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/build.make:90: secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/tfm_internal_trusted_storage.o] Error 1 I think the correct fix is to add the following highlighted code to ps_object_defs.h. Patch is attached. /*! * \struct ps_object_t * * \brief The object to be written to the file system below. Made up of the * object header and the object data. */ struct ps_object_t { struct ps_obj_header_t header; /*!< Object header */ uint8_t data[PS_MAX_OBJECT_DATA_SIZE]; /*!< Object data */ #ifdef PS_ENCRYPTION uint8_t tag_iv[PS_TAG_IV_LEN_MAX]; #endif }; Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

1 year

2
1
0 0

psa_call with NULL outvec causes a NULL pointer dereference

by Quach, Brian

Hi, Is it possible to call psa_call() with NULL outvecs with TF-M v2.0? I am using IPC model. This worked for me with TF-M v1.8 but now I see get a NULL pointer dereference with TF-M v2.0 when psa_reply() is called. Specifically, it happens inside update_caller_outvec_len(). It seems msg.out_size[i] is non-zero (due to a previous psa_call which had 3 outvecs). handle->caller_outvec[i].len causes a NULL pointer deference. void update_caller_outvec_len(struct connection_t *handle) { uint32_t i; for (i = 0; i < PSA_MAX_IOVEC; i++) { if (handle->msg.out_size[i] == 0) { continue; } SPM_ASSERT(handle->caller_outvec[i].base == handle->outvec_base[i]); handle->caller_outvec[i].len = handle->outvec_written[i]; } } spm_associate_call_params() does not clear msg.out_size[] so the previous contents remain. One potential fix is to add the highlighted code below to clear out_size[]. [cid:image001.png@01DA27A5.8860E6F0] Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year

2
3
0 0

Partition log write UART without validation of permissions.

by Roman.Mazurak＠infineon.com

Hi all, I noticed that partition log subsystem uses stdio_output_string through following chain of calls tfm_hal_output_sp_log => SVC TFM_SVC_OUTPUT_UNPRIV_STRING => tfm_hal_output_spm_log => stdio_output_string. SVC handler doesn't validate arguments, so it's allows APP RoT partitions to access PSA RoT memory via partition log subsystem. It seems that tfm_hal_memory_check must be called on SVC handler to validate permissions. Best Regards, Roman.

1 year

2
1
0 0

preload.cmake

by Quach, Brian

Hi, I'm seeing references in the documentation for preload.cmake and several files with that name in TF-M v2.0.0. But looking at the code it seems like preload.cmake was replaced with cpuarch.cmake. Am I missing something? Where should be put fixed platform-specific definitions which are not related to CPU architecture? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

1 year

2
3
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M December 2023