Hi,
Relaying an important announcement about the new Rusted Firmware-A project hosted on trustedfirmware.org:
Today, the Trusted Firmware organization proudly unveils Rusted Firmware-A (RF-A) v0.1 \u2014 a ground breaking open-source prototype that reimagines Trusted Firmware-A (TF-A) through the adoption of the Rust programming language.
Developed in close collaboration between Arm and Google, both Diamond members of the Trusted Firmware community, RF-A has been architected from the ground up for the latest Arm® A-class processors. With a security-first approach, RF-A delivers strong memory safety, enhanced reliability, and modern modularity.
Unlike incremental updates, Rusted Firmware-A is a complete redesign \u2014 free from legacy constraints, built to leverage modern hardware, and designed to provide a robust, maintainable, and future-ready firmware foundation. This milestone reflects years of industry learnings, community insights, and deep collaboration between leading software and silicon providers.
Press release - https://www.trustedfirmware.org/news/rf-a-press-release
Technical blog - https://www.trustedfirmware.org/blog/rf-a-blog
Linkedin post - https://www.linkedin.com/posts/trustedfirmware-org_rusted-firmware-a-rf-a-a…
Regards,
Olivier on behalf of Arm RF-A team.
Hi,
I'm looking for good examples for manifests, both for S-EL1 SPs and
for Hafnium itself. I've seen a few examples, but I'd like to make
sure I'm doing the right thing. What hardware can be described? How is
memory, secure and non-secure, described? Is HW_CONFIG used by
Hafnium? If so, when and what is the format?
Thanks,
Jens
Hi All,
We are pleased to announce the formal release of Trusted Firmware-A version 2.13 bundle of project deliverables.
This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, TF-RMM, Trusted Services, and TF-A OpenCI scripts/jobs components.
These went live on May, 22nd 2025.
Please find references to tags and change logs at the end of this email.
Many thanks to the trustedfirmware.org community for the active engagement in delivering this release!
Notable features of the release version 2.13 are as follows:
TF-A/EL3
* Alto CPU support
*
Architecture feature support for PMUv3p9. PAUTH_LR and SPE_FDS.
* Refactor PSCI to let each CPU core initialise its own context, allowing TF-A to natively handle asymmetric configurations
*
PSCI Powerdown abandon feature support
*
SMCCC_FEATURE_AVAILABILITY support based on SMCCC v1.5 specification
* Firmware Handoff
* Library enhancements to add more TE types in library
* All BL interfaces for FVP are now migrated to use Transfer List along in different boot scenarios (RESET_TO_BL1/BL2/BL31)
*
TC platform is now using Transfer List for booting
* HOB creation Library (from edk2) is now hosted in TF-A
* New Platforms: mt8189, mt8196, qcs615, RK3576, AM62L
Boot flow
* Feature Additions
* Added discrete TPM support in BL1/BL2 for the RPi3 platform.
*
Support for MbedTLS PSA Crypto with ROMLIB on FVP.
*
Redesigned PSA Crypto Key ID management to avoid repeated key creation/destruction.
*
Test Additions
*
Support for MbedTLS PSA Crypto with ROMLIB on FVP.
*
Added basic boot test for TF-RMM with TF-A and TFTF (Realm Payload) in Jenkins CI.
*
Integrated DRTM ACS test suite into TF-A Jenkins CI.
*
Added missing test configuration for ROTPK in register on FVP platform.
*
Build System
*
Refactored ROTPK key/hash generation to auto-generate required files during build.
*
mbedTLS Improvements
*
Migrated to mbedTLS version 3.6.3.
Errata/Security mitigations (CPU/GIC)
*
CVE-2024-5660, CVE-2024-7881
* Cortex-A510, Cortex-A715, Cortex-X4, Cortex-X925, Neoverse V3
Hafnium/SPM (S-EL2)
* FF-A v1.2 completed: indirect messaging with service UUIDs.
* FF-A v1.3 early adoption: Update to FFA_MEM_PERM_GET ABIs.
* StMM integration: provide HOB structure as boot information.
* Power management update:
* Bootstrapped secondary vCPUs on secondary cores power on flows.
* SP's subscription to the power off event.
* SP loading: SP artefacts can be bundled in a TL format. I.e SP binary and SP manifest (DTB).
* Resuming ECs for interrupt handling assisted by NWd Scheduler when the SP is in waiting state, with sri-interrupts-policy field in the SP manifest.
TF-RMM (R-EL2)
* Deprivileging RMM code via EL0 App support
*
Added some support for some RMMv1.1 APIs - "RMI_DEV_MEM_(UN)MAP", support for device granules in "RMI_GRANULE_DELEGATE" and "RMI_GRANULE_UNDELEGATE".
*
Additional hardening of RMM via compiler flags `-fstack-protector-strong`, '-Wextra', '-Wstrict-overflow', '-D_FORTIFY_SOURCE=2' and '-Wnull-dereference'.
*
New platform support for RD-V3-R1 and RD-V3-R1-Cfg1 FVPs.
*
Dynamic discovery of PCIE Root complex topology and device memory from the Boot manifest.
Trusted Services (v1.2.0)
* Introduced the fTPM SP. The implementation is experimental.
*
Introduce the new Arm Reference Design-1 AE platform targeting the Automotive segment. It features
high-performance Arm Neoverse V3AE Application Processor compute system, Arm Cortex-R82AE based Safety Island, and
a Runtime Security Engine (RSE) for enhanced security.
*
Updated the se-proxy deployment and added support for the Firmware Update Proxy service. The FWU Proxy implements a Platform Security Firmware Update for the A-profile Arm Architecture<https://developer.arm.com/documentation/den0118/latest/> compliant FWU Agent which runs a PSA Certified Firmware Update API 1.0<https://arm-software.github.io/psa-api/fwu/1.0/> compliant client as its backend.
TF-A Tests
* Enhancements to fuzzing tests (EL3 vendor specific SMC, SDEI, FF-A interface, capability for randomized fuzzing inputs)
* Functionality test
* Firmware Handoff : AArch32 tests and event log testing
* SMCCC_ARCH_FEATURE_AVAILABILITY
* RAS system registers, FPMR, SCTLR2, THE and D128
* validate psci_is_last_cpu_to_idle_at_pwrlvl
* SPM/FF-A : HOB generation, PPI timer interrupts, v1.2 RXTX headers
* RMM: Tests introduced for majority of features developed in RMM
* Platform Support
* Versal NET
* Versal
* Neoverse-RD
Release tags across repositories:
https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/r…https://git.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/tags…https://git.trustedfirmware.org/plugins/gitiles/ci/tf-a-ci-scripts/+/refs/t…https://git.trustedfirmware.org/plugins/gitiles/ci/tf-a-job-configs/+/refs/…https://git.trustedfirmware.org/plugins/gitiles/hafnium/hafnium.git/+/refs/…https://git.trustedfirmware.org/plugins/gitiles/ci/hafnium-ci-scripts/+/ref…https://git.trustedfirmware.org/plugins/gitiles/ci/hafnium-job-configs/+/re…https://git.trustedfirmware.org/plugins/gitiles/TF-RMM/tf-rmm/+/refs/tags/t…https://git.trustedfirmware.org/plugins/gitiles/TS/trusted-services/+/refs/…
Change logs:
https://trustedfirmware-a.readthedocs.io/en/v2.13.0/change-log.html#id1https://trustedfirmware-a-tests.readthedocs.io/en/v2.13.0/change-log.html#v…https://hafnium.readthedocs.io/en/v2.13.0/change-log.html#v2-13https://tf-rmm.readthedocs.io/en/latest/about/change-log.html#v0-7-0https://trusted-services.readthedocs.io/en/stable/project/change-log.html#v…
Regards,
Olivier.
Hi,
I have a couple of questions related to notification.
Recently, we are working on kernel upgrade and I found this log while booting.
| genirq: Flags mismatch irq 6. 00004401 (ARM-FFA-NPI) vs. 00004400 (IPI)
| ARM FF-A: Error registering percpu NPI nIRQ 6 : -16
| ARM FF-A: Notification setup failed -16, not enabled
This does not affect the other functionalities when I tested using xtest of OP-TEE.
And, I found a commit [1] related this log in linux kernel and it said
| If the firmware returns incorrect SRI/NRI number, we fail to set it up
| in the kernel which is absolutely fine.
So I checked hafnium and I found that hafnium returns "5" as HF_NOTIFICATION_PENDING_INTID [2]
and it conflicts with IPI numbers (IPI_TIMER) [3].
So the question is :
1. HF_NOTIFICATION_PENDING_INTID seems to be conflicted. Do you have any plan to change its number greater than MAX_IPI?
2. Or, Is there the other way to avoid IRQ number conflicts? I mean, Did I miss something to configure?
3. Actually, I haven't find any use-case of notification yet. so notification is still working in progress?
[1] https://lore.kernel.org/linux-arm-kernel/171396205191.700527.18157351542957…
[2] https://github.com/TF-Hafnium/hafnium/blob/main/inc/vmapi/hf/types.h#L62
[3] https://elixir.bootlin.com/linux/v6.14.1/source/arch/arm64/kernel/smp.c#L72
Hi,
You must have noticed slowness or breakages with review.trustedfirmware.org or git.trustedfirmware.org during the week.
There are high and lows of network bandwidth usage affecting server availability.
The issue is being investigated but not yet 100% root caused.
Apologies for the frustration and inconvenience that this is causing.
Rest assured the team is on board to resolve this unfortunate situation.
Regards,
Olivier.
Hi,
As a follow up to the Firmware-A v2.12 release [1], we are pleased to share the shrinkwrap tool [2]
configurations have been updated to consume latest firmware/upstream ingredients using following tags:
TF-A: v2.12.0
TF-a-tests: v2.12.0
Hafnium: v2.12.0
TF-RMM: tf-rmm-v0.6.0
CCA EDK2: 3223_arm_cca_rmm_v1.0_rel0_v3
linux: cca-full/v5+v7
kvmtool: cca/v3
An additional merge request is in queue for kvm-unit-tests update to cca/rmm-v1.0-rel0 tag.
Shrinkwrap is a convenient tool for building a fully integrated Arm CCA SW stack running on
the Base AEM FVP platform. In particular this is the tool of choice for RMM development to
reproduce a 3 or 4 worlds RME based environment.
Regards,
Olivier.
[1] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
[2] https://shrinkwrap.docs.arm.com/en/latest/
+ other MLs
________________________________
From: Olivier Deprez
Sent: 30 October 2024 11:41
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: TF-A Tech Forum regular call
Dear TF-A ML members,
As mentioned in https://www.trustedfirmware.org/meetings/tf-a-technical-forum/, trustedfirmware.org hosts regular technical calls on Thursdays. It mentions TF-A although in practise a number of Cortex-A projects beyond TF-A were discussed (refer to prior recordings on this page).
Unfortunately this slot hasn't been very active recently.
By this email I'm kindly emphasizing this forum is open to the community (and beyond trustedfirmware.org members) and you are welcome to propose topics. Presentations/slides are not strictly necessary, and we can also host informal discussions or session of questions. If you think of a topic, please reach to me and I'll be happy to accommodate.
Thanks for your contributions in advance!
Regards,
Olivier.
Hi,
I have a couple of question about SMP support of linux driver.
We'd like to run multiple SP that uses secondary cores.
The first SP can initialize all secondary vCPUs when linux invokes cpu on for all secondary cores.
But the other SP doesn't initialize its secondary vCPUs.
If My understanding is correct,
they will be initialized when FFA_RUN calls to each vCPUs are called [1]
and FFA_RUN calls are called by Normal world driver in linux [2].
But I can't find any implementations regarding this in the latest upstream linux (v6.10).
Actually, I found ffa_cpu_ops in linux code [3], but couldn't the place where it is used.
I think that ffa_run has to be called in driver to initialize secodary vCPUs of secondary VMs.
Am I missing something in the code?
Or Is there no implementation yet in upstream?
I'd like to know about the current status of secondary VM SMP support in linux.
If linux driver doesn't support it yet,
Do you have any plan to make an implementation and merge it?
Thanks,
Sungbae Yoo.
[1] https://hafnium.readthedocs.io/en/latest/secure-partition-manager/secure-pa…
[2] https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmwa…
[3] https://elixir.bootlin.com/linux/v6.11-rc5/source/drivers/firmware/arm_ffa/…
