Hi all,
TFM in current implementation has following condition in tfm_ns_mailbox.h
#if !defined(TFM_MULTI_CORE_NS_OS) && (NUM_MAILBOX_QUEUE_SLOT > 1)
#error "NUM_MAILBOX_QUEUE_SLOT should be set to 1 for NS bare metal environment"
#endif
I was wondering whether this is real restriction or this check can be removed.
I am not mailbox expert so please correct me if I am wrong.
Quick look at the code shows that it should be ok to have multi slot queue in bare metal environment, with the note that only one slot will be used (as there is only one thread).
If my understanding is correct then it would be nice to remove this compile time check (I am happy to provide a patch for it).
We need this change because we deliver TFM as prebuilt binary and interface (one installed after the build). This binary is built with NUM_MAILBOX_QUEUE_SLOT = 4, so in current implementation it cant be used in bare metal environment.
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>
Hi,
FYI. TF-M Open CI will be on maintenance on 16th Dec.
Time to stop triggering new jobs: 2022-12-16 18:00 UTC
Maintenance end time: 2022-12-16 22:00 UTC
Regards,
Xinyu
From: Kelley Spoon via Tf-openci-triage <tf-openci-triage(a)lists.trustedfirmware.org>
Sent: Thursday, December 15, 2022 4:16 AM
To: tf-openci(a)lists.trustedfirmware.org; tf-openci-triage(a)lists.trustedfirmware.org
Subject: [Tf-openci-triage] [Maintenance] - ci.trustedfirmware.org down time 2022-12-16
Hello All,
The server will be offline to start a maintenance window on 2022-12-16 at 20:00 UTC. Jenkins will be put into "Shutdown Mode" at 2022-12-16 18:00 UTC to stop accepting new jobs and allow executing tasks to complete.
This downtime is required to execute an upgrade for Jenkins to address some security advisories and enable new functionality.
Emails will be sent prior to and following the upgrade to provide status reports.
Start: 2022 12-16 20:00 UTC
End: 2022-12-16 22:00 UTC
Regards,
--
Kelley Spoon <kelley.spoon(a)linaro.org<mailto:kelley.spoon@linaro.org>>
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
