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 All,
The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024.
Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…).
Closing out the release takes around 6-10 working days after the code freeze.
v2.12 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
--
Thanks,
Govindraj R
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 All,
In preparation to the Firmware-A v2.12 bundle release the following TF-A/TF-A-tests/Hafnium/RMM/CI project tags were applied:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a/+/refs/tags/v2.12-r…https://git.trustedfirmware.org/tf-a-tests/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/tf-a-ci-scripts/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/tf-a-job-configs/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/hafnium/hafnium.git/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/+/refs/tags/v2.12…https://git.trustedfirmware.org/ci/hafnium-job-configs.git/+/refs/tags/v2.1…https://git.trustedfirmware.org/TF-RMM/tf-rmm/+/refs/tags/tf-rmm-v0.6.0-rc0
Trees are frozen still accepting security or bug fixes until the release close down happening end next week (hopefully!).
For partners, it will help if tests are run against those trees on downstream platforms and spot any issue hit before the final tagging.
--
Thanks,
Govindraj R
________________________________
From: Govindraj Raja via TF-A-Tests <tf-a-tests(a)lists.trustedfirmware.org>
Sent: Monday, October 14, 2024 20:18
To: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org>; tf-a-tests(a)lists.trustedfirmware.org <tf-a-tests(a)lists.trustedfirmware.org>
Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; tf-rmm(a)lists.trustedfirmware.org <tf-rmm(a)lists.trustedfirmware.org>; trusted-services(a)lists.trustedfirmware.org <trusted-services(a)lists.trustedfirmware.org>
Subject: [Tf-a-tests] Firmware-A v2.12 release code freeze notification
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024.
Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…).
Closing out the release takes around 6-10 working days after the code freeze.
v2.12 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
--
Thanks,
Govindraj R
--
TF-A-Tests mailing list -- tf-a-tests(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-a-tests-leave(a)lists.trustedfirmware.org
+ 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 All,
This is a follow-up email to the OP-TEE 4.4.0 release, highlighting the updates to the SPMC and related components.
Short summary of the introduced changes:
- Branch Target Identification (BTI) and Pointer Authentication (PAC) support added for S-EL0 Secure Partitions
- FF-A VM availability message forwarding support added to S-EL0 Secure Partitions
- Improved FF-A compliance
For more details on how to get, build and test the SPMC, please see [1].
Regards,
Imre
[1]: https://github.com/Trusted-Services/trusted-services/wiki/OP-TEE-SPMC-v4.4-…
Hey, I have some issues understanding a few things related to
https://www.trustedfirmware.org/, specifically:
-
https://trustedfirmware-a.readthedocs.io/en/latest/components/firmware-upda…
PSA Firmware Update (PSA FWU)
-
https://trusted-services.readthedocs.io/en/latest/services/fwu/index.html
Firmware Update Service
I’ve asked on other mailing lists, but unfortunately, no one responded.
I’m writing this in the context of ARMv8 architecture machines, where
(roughly) we have the following stack running:
- payload understandable by the vendor's bootROM
- TF-A BL2
- TF-A BL31 as EL3 runtime services
- OP-TEE as BL32
- u-boot as BL33
- Linux
I will refer to BL31 and BL32 as firmware.
In the PSA Firmware Update specification, the entire procedure is
described, outlining how it should work, e.g., the update process is
initiated by the Update Client running in REE (e.g., some process on
Linux), and it describes how metadata should be handled, rollback, etc.
Assuming that my storage is eMMC, where all these things are stored,
divided into partitions (let's skip offsets and other details):
- bootROM payload
- bl2
- fip-a (required by bl2 with PSAFWUSUPPORT)
- fip-b (required by bl2 with PSAFWUSUPPORT)
- metadata-a (required by bl2 with PSAFWUSUPPORT)
- metadata-b (required by bl2 with PSAFWUSUPPORT)
- boot (e.g., with fitimage)
- rootfs-a
- rootfs-b
- data
As I was reviewing the specification, it seemed that the firmware update
should be conducted in the secure world, which (in my opinion) would mean
that, for example, fip-x and metadata-x are updated somehow from the secure
world, let’s say by a TA running in OP-TEE. However:
- OP-TEE doesn't have drivers for eMMC (simply put - for example, to
store data securely, OP-TEE communicates with Linux to write data to eMMC).
- When I started googling and asking around (e.g., on Reddit), people
told me that it's not the case at all, and typically some process runs on
Linux, like RAUC or SWUPDATE, and it just writes whatever is needed to
fip-x and metadata-x - so the whole update takes place in the so-called REE.
And now my question is - I assume that this specification and trusted
services (particularly the FWU service) that I linked were designed for a
reason - so my question is, what is the use case? Could this be more
applicable to "small MCUs" rather than microprocessors (even though the
specification I linked concerns Cortex-A)? Or is this used on servers?
Perhaps the nature of embedded systems is such that we don't use it and
just take RAUC or some other SWUPDATE and write what is needed, and the
fact that the system is trustworthy is ensured by the chain-of-trust?
Best regard
Patryk
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.11 has an expected code freeze date of May, 10th 2024.
Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…).
Closing out the release takes around 6-10 working days after the code freeze.
v2.11 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
Thanks & Regards,
Olivier.
