- Trusted-services - lists.trustedfirmware.org

by Govindraj Raja

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-rc0 https://git.trustedfirmware.org/ci/tf-a-ci-scripts/+/refs/tags/v2.12-rc0 https://git.trustedfirmware.org/ci/tf-a-job-configs/+/refs/tags/v2.12-rc0 https://git.trustedfirmware.org/hafnium/hafnium.git/+/refs/tags/v2.12-rc0 https://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

23 hours, 24 minutes

2
3
0 0

Firmware-A v2.15 release code freeze notification

by harrison.mutai＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

1 month

1
0
0 0

How trusted Service to obtain the physical address of a buffer for DMA.

by Kummari, Prasad

[AMD Official Use Only - AMD Internal Distribution Only] Hi Team, I am working on a Trusted Service running under OP-TEE SPMC (FF-A based setup) on ARMv8. We are implementing a block storage service that reads data from OSPI flash using a DMA engine. Currently, the Trusted Service allocates a buffer and passes it to the DMA engine, but the read operation returns all zeros. I suspect this is because the buffer is a virtual address, while the DMA expects a physical address. My questions: 1. Is there a supported way for a Trusted Service to obtain the physical address of a buffer? 2. If not, what is the recommended approach for handling DMA in this context? Should this be done outside the Trusted Service using shared memory? Any guidance would be appreciated. Regards, Prasad.

1 month, 1 week

1
0
0 0

Trusted Firmware v2.14 release announcement

by Olivier Deprez

Hi, We are pleased to announce the formal release of Trusted Firmware-A version 2.14 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 Nov, 24th 2025. Please find tag references 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.14 are as follows: TF-A/EL3 * New architectural features support: FEAT_FGWTE3, FEAT_IDTE3, FEAT_RME_GPC2, FEAT_AIE, FEAT_CPA2, FEAT_MPAM_PE_BW_CTRL, FEAT_PFAR, FEAT_RME_GDI. * Live Firmware Activation: base support enabling TF-RMM LFA, added RMM MEM RESERVE ABI. * Armv9 CPU power down abandon support * GICv5 driver permitting normal world kernel boot * GIC720-AE support added * Per-cpu framework supporting NUMA platforms * SMCCC SoC name support (SMCCC v1.6 SMCCC_ARCH_SOC_ID) * SPMD: added FF-A v1.3 FFA_NS_RES_INFO_GET, FFA_ABORT interfaces * EL3 SPMC: add multiple UUIDs support, TPM event log delivered by HOB list, FFA_MEM_RETRIEVE_REQ from hypervisor * RME: FEAT_D128 for realm world, SMCCC_ARCH_FEATURE_AVAILABILITY * Platforms: RD-Aspen added, updates to Arm FVP/Juno, AMD Versal Gen2, Intel, MT8189, MT8196, i.MX94, i.MX95, S32G274A, QTI Kodiak, Renesas R-Car, STM32MP1, STM32MP2, STM32MP21, STM32MP25, Xilinx Versal, ZynqMP Boot flow * Transfer list and event log libraries now offered as shared libraries consumed as submodules by TF-A. * Update to mbedTLS 3.6.5 * Various PSA FWU improvements, namely BL2 in a dedicated FIP, GPT-corruption notifications to BL32, and expanded FWU tests. Errata/Security mitigations (CPU/GIC) * New CPU support: Arm Lumex C1, Dionysus, Caddo/Veymont, Venom. * Added close to 30 new CPU errata across multiple processor families, based on the latest SDEN updates. Hafnium/SPM (S-EL2) * FF-A v1.3 early adoption * FFA_NS_RES_INFO_GET ABI added * Partition lifecycle support: new states, abort handling. Pre-requisite to secure partitions live firmware activation. * Notifications support refactored with per-vCPU notifications removed. * Multi-GIC configuration supporting complex topologies. * Shrinkwrap used at core of Hafnium testing infrastructure. TF-RMM (R-EL2) * RMM v1.1 Planes support * PMU, timer, GIC ownership transfer. * Support for FEAT_S1POE/S1PIE, FEAT_S2POE/S2PIE * RMM v1.1 Memory Encryption Contexts (MEC) support * Realm Device Assignment * RMM v1.1. ALP12 base Device Assignment support * RMI VDEV ABIs, PDEV life cycle, root port IDE key programming, SPDM client as EL0 app. * Improved ID registers trapping leveraging SMCCC ARCH_FEATURE_AVAILABILITY, in light of future FEAT_IDTE3 support. * Additional architectural support: FEAT_TCR2, FEAT_D128, single-copy atomics, TF-A Tests * RME: DA and PCIe, Planes, MEC * SPM/FF-A * Bumped support o FF-A v1.3 * FFA_ABORT ABI * Deprecated per-vCPU notifications. * FWU: added negative testing (invalid image size, corrupted ROTPK) * GICv5 support added * Arm architecture tests * FEAT_TCR2 (for RME) , FEAT_IDTE3, FEAT_MPAM_PE_BW_CTRL, FEAT_EBEP, FEAT_AIE, FEAT_PFAR * SMCCC_ARCH_SOC_ID * SMCCC_ARCH_FEATURE_AVAILABILITY * Fuzzing: added SMC fuzzer documentation * Basic LFA framework tests * Platforms updates: AMD/Xilinx, Arm FVP, Corstone-1000 Trusted Services * RD-Aspen platform support added. * EFI ESRT handling in FWU Proxy (supporting Corstone1000 platform). * Block Storage service threat modelling. 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/+/refs/tags… 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.14.0/change-log.html#id1 https://trustedfirmware-a-tests.readthedocs.io/en/v2.14.0/change-log.html#v… https://hafnium.readthedocs.io/en/v2.14.0/change-log.html#id1 https://tf-rmm.readthedocs.io/en/tf-rmm-v0.8.0/about/change-log.html#v0-8-0 https://git.trustedfirmware.org/plugins/gitiles/TS/trusted-services/+/refs/… Regards, Olivier.

6 months

1
0
0 0

Firmware-A v2.12 release code freeze notification

by Govindraj Raja

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

7 months, 2 weeks

2
3
0 0

Rusted Firmware-A is live!

by Olivier Deprez

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.

9 months, 2 weeks

1
0
0 0

Trusted Firmware v2.13 release announcement

by Olivier Deprez

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#id1 https://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-13 https://tf-rmm.readthedocs.io/en/latest/about/change-log.html#v0-7-0 https://trusted-services.readthedocs.io/en/stable/project/change-log.html#v… Regards, Olivier.

1 year

1
0
0 0

trustedfirmware git and gerrit slowness

by Olivier Deprez

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.

1 year, 1 month

1
0
0 0

Trusted Firmware v2.12 release announcement

by olivier.deprez＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

1 year, 6 months

1
0
0 0

Re: TF-A Tech Forum regular call

by Olivier Deprez

+ 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.

1 year, 7 months

1
0
0 0

2026

2025

2024

2023

2022

Trusted-services