- TF-M - lists.trustedfirmware.org

by Bohdan.Hunko＠infineon.com

Hi all, Our team is working on TFM threat modeling, we are analyzing existing code to find and fix any security issues/problems with it. To better perform this modeling we are interested in having detailed diagrams of TFM boot and execution flows. Ideally the diagrams should be quite detailed to show system state transitions, detailed execution flow and any actions that are not obvious when first looking into TFM code (e.g. scheduling of nested calls, execution of secure IRQs that interrupt nested scheduling, ....). Does TFM community have such (or similar) diagrams/? If so then where can we find them? We think that these diagrams may be very useful to TFM in general. They will let TFM users easily understand how TFM works (in details). 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>

2 years, 10 months

2
1
0 0

Start of TF-M v1.7.0 release process

by Anton Komlev

Hello, The branch release/1.7.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 successful run of the basic tests. Let me remind that the code is not frozen, and development can be continued on the main branch. Thanks, Anton

2 years, 10 months

1
3
0 0

CMake 3.25.0 build issue

by Bøe, Sebastian

Hi, when I updated from CMake 3.24.0 to the new (two weeks old) CMake 3.25.0 I am no longer able to build TF-M with -DTEST_PSA_API=CRYPTO. (Downgrading CMake fixes the issue) Is there an interoperability issue with the latest CMake release and the TF-M build system? Reproduced with TF-Mv1.7.0-RC1 TF-Mv1.6.0 Steps to reproduce: 1. install CMake 3.25.0. 1. cd trusted-firmware-m 1. rm -rf cmake_build && cmake -G Ninja -S . -B cmake_build -DTEST_PSA_API=CRYPTO -DTFM_PLATFORM=nordic_nrf/nrf5340dk_nrf5340_cpuapp -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug && ninja -C cmake_build Only reproduces with TEST_PSA_API and CMake 3.25.0. Builds fine with 3.24.0 or non-PSA API builds. error: file INSTALL cannot find "/home/sebo/ncs/modules/tee/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/src/psa_generate_database-build/target_database.h": No such file or directory.

2 years, 11 months

3
2
0 0

Trusted Firmware M build error on Windows 10

by Pocsai Ildiko LCPF-CH

Hello, I'm trying to build the Trusted Firmware M on Win10 x64 for NXP LPC55S69 using the IAR compiler, but I get the following error: [ 76%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/nxp/lpcxpresso55s69/Device/Source/startup_lpcxpresso55s69.o extern uint32_t __INITIAL_SP; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe007]: unrecognized token extern uint32_t __INITIAL_SP; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe065]: expected a ";" extern uint32_t __INITIAL_SP; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe007]: unrecognized token extern uint32_t __STACK_LIMIT; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe007]: unrecognized token extern uint32_t __STACK_LIMIT; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe065]: expected a ";" extern uint32_t __STACK_LIMIT; ^ "C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe007]: unrecognized token (VECTOR_TABLE_Type)(&__INITIAL_SP), /* Initial Stack Pointer */ In the attachment, you can find the full build log and also the CMake build file generation log. Some details about my setup: Win10 Enterprise x64. Version 20H2 IAR ANSI C/C++ Compiler V8.50.9.278/W32 for ARM GNU Make 3.81 git version 2.36.0.windows.1 CMake 3.24.2 Python 3.10.5 I followed the steps from the Getting started guide here<https://tf-m-user-guide.trustedfirmware.org/getting_started/index.html> than the steps to build the framework for LPC55S69 here<https://tf-m-user-guide.trustedfirmware.org/platform/nxp/lpcxpresso55s69/RE…>. Do you have any idea what I'm missing? In case you need any further information let me please know. Thanks in advance. Kind regards, Ildikó Pocsai

2 years, 11 months

6
11
0 0

Number context for NS

by Michel JAOUEN

Hello, I see that in coming 1.7.0 the file secure_fw/spm/ns_client_ext/tfm_ns_ctx.h contains a comment /* Supported maximum context for NS. Only support single context for now. */ #define TFM_NS_CONTEXT_MAX 1 Does it mean that several simultaneous NSC call is not supported ? Best regards ST Restricted

2 years, 11 months

2
1
0 0

Interrupt SLIH Scheduling

by vivahavey＠gmail.com

Dear developers, I have a question about interrupt SLIH scheduling in IPC model. Assume that there are two secure partitions P1 and P2, and P1 has higher priority than P2. P1 calls psa_call(), so SPM blocks P1 and wakes up P2 to execute P2's service handler. Now P2 is running. Suddenly P1's interrupt occuerred, and P1's SLIH signal is asserted for more processing. A shedule request is also triggered. Since P1 has higher priority than P2, will P2 be preemted by P1 to execute P1's SLIH immediately? If the answer is yes, the psa_call() chain will be corrupted, right? Thanks in advance. Alvin Chang

2 years, 11 months

3
3
0 0

Platform/Application specific service extension

by Roman.Mazurak＠infineon.com

Hi, Partition is described through configuration in YAML files (manifests). This configuration includes following properties (see Adding Secure Partition - Add manifest<https://tf-m-user-guide.trustedfirmware.org/integration_guide/services/tfm_…>): * Name, type, priority, model, ... * List of services provided by partition * MMIO regions * List of IRQs * Dependencies Each platform should provide implementation of HAL which is specific to standard partitions like Crypto, ITS, etc. It's mandatory to provide proper isolation of memory/peripheral that are used by platform specific code that provides HAL implementation or add a custom dependency for standard partition. Currently platform can use following approaches to resolve the problem of extending YAML of standard TF-M partition: * Create a platform specific copy of partition YAML, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15639 as an example of such approach. * Modify standard partition by introducing optional fields, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/17718. These both solution are not flexible enough. It requires to modify platform independent code or maintain own copy of partition YAML file with needed changes. I think it make sense to integrate partition YAML extension tool in TF-M. Platform/application should be able to provide manifest-extension file(s). Such manifest-extension file may provide additional properties which should be joined with properties provided by standard partition manifest files. For example to solve problem for https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15639 ARM RSS platform may provide following manifest-extension file with structure like this: { "extensions": [ { "name": "TFM_SP_INITIAL_ATTESTATION", "dependencies": [ "TFM_MEASURED_BOOT" ] } ] } Tool which parses manifests should add a new dependency on "TFM_MEASURED_BOOT" to list of dependencies for "TFM_SP_INITIAL_ATTESTATION" partition. Please, share your opinion on this topic. Best regards, Roman.

2 years, 11 months

2
1
0 0

Deleting last object in a data block in ITS filesystem

by Stefan Krug

Hello! Seemingly, there is an issue with file deletion in ITS. I would think it is not possible to delete the last object in a data block (so that the data block becomes empty). It's easiest to reproduce with using large objects (because then the number of involved objects is small), but would also happen with multiple smaller objects: With the following flash configuration: ITS_MAX_ASSET_SIZE=0x1000 TFM_HAL_ITS_SECTORS_PER_BLOCK=1 TFM_HAL_ITS_FLASH_AREA_SIZE=0x20000 TFM_HAL_ITS_PROGRAM_UNIT=0x100 ITS_FLASH_NAND_BUF_SIZE=1*0x1000 In a sequence of writing and deleting an object like: const uint8_t big_file[ITS_MAX_ASSET_SIZE] = {0}; status = psa_its_set(uid, sizeof(big_file), big_file, flags); status = psa_its_remove(uid); deleting the file fails with the status of PSA_ERROR_GENERIC_ERROR. What I think happens is: Due to the size of the file, it does not fit in the metadata block, and is put a second (data only) block. The object is written there as expected. When the data block is deleted later, an attempt is being made to compact it with its_flash_fs_dblock_compact_block(). However, there is no data to keep before the object to be deleted and also no data to keep after it, this block will become empty, so no call to its_flash_fs_block_to_block_move() happens, which causes no call to fs_ctx->ops->write() happens. Now the flash driver in my case is a buffering its_flash_nand.c. In the write() call it would associate a buffer for the physical sector to write. But since there is no write() call the subsequent fs_ctx->ops->flush() fails as it has no buffer to flush out. I believe no compaction of the block should even be attempted - it is known that the block will be empty beforehand. Perhaps similar to https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/17578, this is yet another reason to skip compacting of the block? It would be very much appreciated if one of the experts could confirm this suspicious behavior or point out a mistake I am making. Thank you very much, best regards Stefan Krug

2 years, 11 months

2
1
0 0

Announcing TF-Mv1.6.1 fix

by Anton Komlev

Hello, This is an announcement of TF-M v1.6.1 hotfix preparation. The reason for the hot fix is the recently found incorrect stack sealing in Library model. The library mode is deprecated already but is available in v1.6.0 and the intention is to leave it in the best shape to our knowledge. Security analysis shows no vulnerability was brought by this defect, so it is not a security fix. The plan is to issue the fix by Nov 17. TF-M release cadence and process is here: https://tf-m-user-guide.trustedfirmware.org/releases/release_process.htmlte… Thanks, Anton

2 years, 11 months

1
1
0 0

TF-M Profile Medium-ARoT-less

by David Hu

Hi all, TF-M Profile Medium-ARoT-less is proposed to align with PSA Certified ARoT-less Level 2 protection profile [1]. May I ask for your review and comment please? Please check following patches: https://review.trustedfirmware.org/q/topic:%22arot-less%22+(status:open%20O… Any feedback is welcome. [1] https://www.psacertified.org/app/uploads/2022/10/JSADEN019-PSA_Certified_Le… Best regards, Hu Ziji

2 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M