Hello,
I am pleased to announce the release of TF-M v1.7.0.
New major features are:
* Unified API to PSA Service access implementing PSA FF-M and FF-M v1.1 extension
* The Library model is deprecated and removed
* Improve and simplify TF-M configurability
* Introduce the base configuration for TF-M essential
* Shift config options from CMake to C header files for PSA modules and platforms
* Employ Kconfig as a configuration tool and dependency tracker
* Configurable stack size for Secure Partitions
* Add TF-M Medium-ARoT-less profile
* MM-IOVEC deployed in PSA Secure Partitions
* PSA FWU API updated to v1.0
* Mbed TLS updated to v3.2.1
* Code size further optimised
* The manifest tool is decoupled with the build system
* Improvements in the Code size analysis tool
* Updated documentation
It is tagged with TF-Mv1.7.0<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.7…>.
The release time changes will be integrated with the main branch shortly.
Many thanks everyone for contribution, review and support this milestone.
Anton
Hello,
We are currently integrating a protocol stack with a Radio IRQ in a TrustZone environment with the TF-M as the SPE.
The Radio IRQ requires fast treatment from our protocol stack, the need is to have the Radio IRQ handled with the lowest latency possible.
The fact that all the IRQs in the NonSecure side can't preempt IRQ on the Secure side in the TF-M design leads us to the following possibilities with several limitations:
1. Having the Radio IRQ as the lowest priority on the NonSecure side: if a user creates its own partition with an IRQ (which by design will have a lower priority of our IRQ because it's in the Secure side), it could potentially delay for too long the Radio IRQ processing, thus leading to Radio protocol related issues.
1. Having the protocol stack related to the Radio IRQ in a partition directly in Secure side : this configuration is highly disputable from a Security point of view, the possibility to introduce a Security flaw with the protocol stack in Secure being too high.
1. Having the Radio IRQ in a Secure partition (FLIH for faster handling) and forward the IRQ handling to the protocol stack in the NonSecure side, all modifications to the NVIC registers of this Radio IRQ (enable, disable, priority level) requested by the protocol stack in NonSecure side will have to be done through this partition with TF-M API calls (SFN backend for execution performances) : This configuration will probably led to issues such as reentrancy on the TF-M (for example if the TF-M forward an IRQ to the NonSecure which then calls TF-M API for Radio NVIC register manipulations) or having to call TF-M from NonSecure in handler mode.
Do you already have experienced with this type of problematics, or do you see TF-M configurations which will be more suitable for such a use-case ?
Thank you,
Regards,
Romain
ST Restricted
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>
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
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.
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
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
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
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.
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
