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
