Hello,
I am thrilled to announce the support of new Clan/LLVM toolchain, freely available here: https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm. This extends a suite of powerful tools designed to enhance your development experience and boost productivity.
Key Features:
* Offers Clang frontend
* Available for Linux, Windows and macOS
* Builds TF-M binaries for all Arm targets
* Secure side built without libc and picolib libraries, while both are available to Bootloader and Non-Secure side
Important notes:
* Floating point support is not verified
* MVE is not supported yet
* This has been verified with version v18.1.3 of the toolchain.
We're excited for you to try out the new toolchain support and look forward to your feedback. The use of the toolchain_CLANG.cmake is the same as all other toolchains.
I plan to present the new toolchain and compare it with the existing tools in one of the upcoming TF-M forums. Meanwhile I encourage the platform owners to include the new toolchain support using arm platforms as a reference. The relevant changes are in this chain:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34351
There is ongoing discussion on the best name for the toolchain to avoid possible confusion. Should it be Clang as now, LLVM, or even LLVMClang? Please share your opinion.
Thanks, and best regards,
Anton.
Hello,
As latest TFM version now supports MbedTLS 4.0 which use TF PSA CRYPTO (I understood only PSA API are available and no more mbed API)
Don't you think that the default value for MCUBOOT_USE_PSA_CRYPTO in file : \trusted-firmware-m\bl2\ext\mcuboot\mcuboot_default_config.cmake should be ON instead of OFF ?
Thank you.
Ronan,
[Shape, rectangle Description automatically generated]
Ronan GABOU
MDRF / Embedded Processing / General Purpose and Automotive MCU / Ecosystem / Security
STMicroelectronics
134 avenue Aristide Briand, 92120 Montrouge, France
This communication is confidential and intended solely for the addressee(s). If you are not the intended
recipient, you should not review, retain, copy or distribute the e-mail itself or the information it contains.
In such case, we kindly request you notify the sender by replying to this transmission and delete the
message without disclosing it. Thank you!
[cid:image002.png@01DC99E8.84F4A440]<https://www.facebook.com/STMicroelectronics.NV/> [cid:image003.png@01DC99E8.84F4A440] <https://twitter.com/st_world> [cid:image004.png@01DC99E8.84F4A440] <https://www.linkedin.com/company/stmicroelectronics/> [cid:image005.png@01DC99E8.84F4A440] <https://www.instagram.com/stmicroelectronics.nv/> [cid:image006.png@01DC99E8.84F4A440] <https://www.youtube.com/user/STonlineMedia> ST online: www.st.com
Hi all,
I am trying to build psa-arch-tests for the latest master but I am getting these king of build errors:
error: unknown type name 'psa_key_handle_t'; did you mean 'psa_handle_t'?
23 | static psa_key_handle_t public_key_handle;
From what I can tell – psa arch tests have not yet been adapted to new PSA crypto headers. Am I correct? When can we expect this change to be available?
Best regards,
Bohdan Hunko
Cypress Semiconductor Ukraine LLC
Senior Engineer
CSS ICW SW INT BFS SFW
Mobile: +380995019714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi,
I recently started seeing a build error for PSE84. "git bisect" tells me that it was introduced in c2fc818e.
The error is from cmake, complaining about a circular dependency. The error message itself is extremely long, so I've attached it as a separate file.
Chris
Hi everyone,
We are happy to announce that TF-M has transitioned to a standalone PSA Crypto component (TF-PSACrypto), a major milestone in the project’s development. TF-PSACrypto provides a reference PSACrypto implementation that is separated from the MbedTLS project. There are a few known issues, including platform support, which we expect to address before the next TF-M release.
Thanks to everyone involved in the development, review and testing, especially the PSA Crypto team for releasing TF-PSACrypto and David Vincze for adapting TF-M to it.
As always, we welcome feedback from the community.
Best regards,
Anton
Hi all,
I have found a bug in SPM scheduler lock logic – this bug is extremely hard to reproduce as it requires precise conditions and timings, but here is the description of the bug scenario:
1. Partition A calls psa_wait to wait for a signal (this signal is going to be asserted by FLIH IRQ later)
2. Currently signal is not asserted, no other partition is runnable, thus SPM marks this signal as being awaited and then schedules idle_thread
3. idle_thread calls psa_wait to poll SPM
* psa_wait calls tfm_arch_thread_fn_call
* tfm_arch_thread_fn_call calls backend_abi_entering_spm
* backend_abi_entering_spm calls arch_acquire_sched_lock
* arch_acquire_sched_lock sets scheduler_lock = SCHEDULER_LOCKED
* psa_wait (called by idle_partition) is being processed up to the point of backend_abi_leaving_spm
* backend_abi_leaving_spm calls arch_release_sched_lock
* here is where very sneaky the bug happens
* arch_release_sched_lock executes following assembly instructions
i. "ldr r1, =scheduler_lock \n"
"ldr r0, [r1, #0] \n"
ii. At this point r0 holds scheduler_lock is = SCHEDULER_LOCKED
iii. After these instructions are executed FLIH interrupt arrives
* FLIH handler asserts signal (which should unblock execution of the Partition A)
* spm_handle_interrupt calls backend_assert_signal
* backend_assert_signal does
if (p_pt->signals_asserted & p_pt->signals_waiting)
and returns STATUS_NEED_SCHEDULE
* spm_handle_interrupt calls arch_attempt_schedule
* arch_attempt_schedule checks value of scheduler_lock (which is SCHEDULER_LOCKED) and sets scheduler_lock= SCHEDULER_ATTEMPTED
* Interrupt returns
iv. Execution continues, now scheduler_lock is = SCHEDULER_ATTEMPTED
But the next line of code in arch_release_sched_lock is
"movs r2, #"M2S(SCHEDULER_UNLOCKED)" \n"/* Unlock scheduler */
This effectively overwrites scheduler_lock from SCHEDULER_ATTEMPTED to SCHEDULER_UNLOCKED
This means that following SRM scheduling logic will not trigger PendSV and just return to idle_partition – effectively resulting in a hang of a system.
Looks like the solution is to wrap lock logic in critical section. But may be there is other things that can be done to better fix this issue.
Let me know if there are other details that may be helpful to fix this bug.
Bohdan Hunko
Cypress Semiconductor Ukraine LLC
Senior Engineer
CSS ICW SW INT BFS SFW
Mobile: +380995019714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi all
I see that https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/44534 added tfm_s_build_flags for all the compilers except IAR
After version update - in our CI we see:
Fatal error[Ms007]: could not open file "libtfm_s_build_flags.a"
Is this intentional change or IAR file was just missed and the change should also be added for IAR?
Best regards,
Bohdan Hunko
Cypress Semiconductor Ukraine LLC
Senior Engineer
CSS ICW SW INT BFS SFW
Mobile: +380995019714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi. Anton Komlev.
I'm phillip kim (jonghyeok kim).
I have posted a new thread on https://lists.trustedfirmware.org/
But, I can't find my thread.
I have heard this website had some problem.
The thread i posted is below.
=================================================================================================================
Hello all,
I'm developing the RSE Firmware based on rdv3r1.
And I'm trying to use ADAC feature.
I found conflicted ADAC Configuration.
Below file, the adac is app rot.
\tf-m\cmake_build\rdv3r1\0\lib\ext\tf-m-extras-src\partitions\adac\CMakeLists
And Below file, the adac is psa rot.
\tf-m\cmake_build\rdv3r1\0\lib\ext\tf-m-extras-src\partitions\adac\tfm_adac.yaml
Please explain about each two files.
1) Platform (arm neoverse RDV3R1 (RSE))
repo init -u https://git.gitlab.arm.com/infra-solutions/reference-design/infra-refdesign-... -m <manifest-file-name> -b refs/tags/<RELEASE_TAG> --depth=1
repo sync -c -j $(nproc) --fetch-submodules --force-sync --no-clone-bundle
manifest file: pinned-rdv3r1.xml
release tag: refs/tags/RD-INFRA-2025.07.03
2) Enabling the ADAC Parameter
set(PLATFORM_PSA_ADAC_SECURE_DEBUG TRUE CACHE BOOL "Whether to use psa-adac secure debug.")
set(PLATFORM_PSA_ADAC_VERSION "cbd17d8" CACHE STRING "The version of psa-adac to use.")
set(TFM_EXTRAS_REPO_EXTRA_PARTITIONS "adac;measured_boot;delegated_attestation;dice_protection_environment;scmi" CACHE STRING "List of extra secure partition directory name(s)")
set(TFM_EXTRAS_REPO_EXTRA_MANIFEST_LIST "partitions/adac/adac_manifest_list.yaml;partitions/measured_boot/measured_boot_manifest_list.yaml;partitions/delegated_attestation/delegated_attestation_manifest_list.yaml;partitions/dice_protection_environment/dpe_manifest_list.yaml" CACHE STRING "List of extra secure partition manifests")
set(TFM_PARTITION_ADAC ON CACHE BOOL "Whether to use psa-adac secure debug.")
3) Build Command
./build-scripts/build-test-uefi.sh -p rdv3r1 build
Thanks
Best Regards
Phillip
=================================================================================================================
Thanks
Hi,
In our local copy of TFM we are running Coverity tools which performs MISRA, CERT-C and CODING static analysis checks on TFM codebase (I will refer to this as MISRA fixes for simplicity). During our development we did a bunch of fixes for the violations (not all rules but still significant number of changes). Most of these changes are small (e.g. U/UL postfixes, fixed width types usage, header file fixes etc…).
When we do version updates or generally port code between upstream and local copy of TFM we have to deal with merge conflicts in these lines effected by MISRA fixes.
To avoid these issues we would like to push these fixes upstream.
There are quite a few changes and having everything in one patch will really simplify our work as we would not have to divide the changes.
We would like to know whether creating one bigger patch with all the changes would be acceptable for the review?
Best regards,
Bohdan Hunko
Cypress Semiconductor Ukraine LLC
Senior Engineer
CSS ICW SW INT BFS SFW
Mobile: +380995019714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>