Hi Everyone,
The RMM v2.0 Beta 0 specification has been published here:
https://developer.arm.com/documentation/den0137/latest/
As you may have noticed, this release introduces breaking changes to the RMI APIs (host side), while the RSIs (guest side) remain backward compatible. Nearly all ABIs are affected, and the scope of these changes makes it highly disruptive to maintain support for both RMI v1.x and RMI v2.0 within the same codebase. We do not expect RMI v1.x to be deployed in production, and retaining support for it would increase development overhead and the risk of introducing bugs.
A more pragmatic approach is to branch the current RMM codebase at the RMI v1.x ABI and then migrate the mainline to the RMI v2.0 ABI. This will be a breaking change for host-side components that rely on the older RMI ABI. Given the extent of the ABI changes, significant effort will be required to align with RMI v2.0, and this approach allows the team to focus on upstreaming the new ABI support efficiently.
The initial RMI v2.0 upstreaming will consist of a series of commits that together form an initial RMM implementation targeting the RMM v2.0 specification. This initial implementation will not be fully feature-complete with respect to the v2.0 spec, and we expect to continue layering additional RMM v2.0 ABI-related changes on top as the implementation matures during the course of the year.
That said, we intend to maintain integration with an externally available, compatible Linux host kernel branch throughout this process. The initial RMI v2.0 RMM implementation will be compatible with an initial v2.0-based host kernel, and we will notify the mailing list once this integration is available to pick up (likely end of March '26). If and when we need to introduce further ABI changes that break compatibility with a previously published kernel branch, we will call this out explicitly in advance and indicate when an updated kernel branch will be available for integration.
We plan to keep RMI v1.x ABI as a separate branch and selectively merge bug fixes on a request or need basis. Please let us know if you have any concerns regarding this plan within the next two weeks.
Best Regards
Soby Mathew
Hello,
We are observing a recurring virtual‑timer IRQ loop during Realm guest bring‑up under TF‑RMM with RME enabled. The problem seems to be an ordering issue around restoring Realm timer state at EL2 and subsequently evaluating pending timer conditions.
When a virtual-timer interrupt is taken to EL2-R, the timer registers (CNTV_CTL=0x5 and CNTV_CVAL) are saved, and the IRQ is then reported to host OS.
When EL2 restores CNTV_CTL and CNTV_CVAL on return from the host, the write sequence is not synchronized before EL2 performs the timer‑pending check in the function check_pending_timers(). Because CNTVCT continues to advance, and CNTV_CVAL < CNTVCT is already true at restore time, the read of CNTV_CTL can reflect a stale value (0x1). As a result, EL2 does not set CNTHCTL_EL2.CNTVMASK, fails to clear the pending virtual‑timer interrupt, and the IRQ is re‑asserted immediately upon Realm re‑entry—causing the repeated exit/entry loop.
Inserting an isb() after restoring the Realm’s timer registers and before performing the timer‑pending check helped resolve the issue.
I’d appreciate any feedback.
Thanks
Hi, On Dec 11th in the TF-A Tech Forum at 4.00pm UK, Soby Mathew will
present a design update on TF-RMM Live Firmware Activation: This
presentation describes the revised TF-RMM Low-VA MMU and
global-runtime-data design required to support Live Firmware Activation
(LFA). Compared to the earlier approach (outlined in the TFA Tech Forum
session on 12-Jun-2025 [1] ), which assumed mostly fixed boot time mappings
and per-platform handcrafted Low-VA contexts, the new design is driven by
several changes in RMM specification: RMM must now support runtime
mapping/unmapping of PAs for RMM objects like struct granule , reuse those
dynamic mappings across LFA transitions. These PAs can come either from NS
world at runtime or EL3 reservation from RMM carveout. In order to migrate
Stage 1 dynamic mappings across LFA instances, RMM needs to reduce
dependence on platform-specific MMU setup, and provide a structured
framework for allocating, versioning and migrating global runtime data. The
Stage 1 Low-VA is therefore split into static and dynamic regions managed
by the common xlat layer. The detailed design is captured in the TF-RMM
wiki RFC “TF-RMM Live Firmware Activation [2]” and builds on the initial
design presented in the TFA Tech Forum session on 12-Jun-2025 [1] : [1]
Previous LFA discussion:
https://github.com/TF-RMM/tf-rmm/wiki/TFA-Tech-Forum-Presentations [2]
https://github.com/TF-RMM/tf-rmm/wiki/RFC:-TF%E2%80%90RMM-Live-Firmware-Act…
Regards, Olivier.
TF-A Tech Forum
Thursday Dec 11, 2025 ⋅ 5pm – 6pm
Central European Time - Paris
Location
https://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34…https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9355786…
Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-A
Tech ForumTime: May 15, 2025 02:00 PM London Every 2 weeks on Thu,
78 occurrence(s)Please download and import the following iCalendar (.ics)
files to your calendar
system.Weekly: https://linaro-org.zoom.us/meeting/tJcocu6gqDgjEtOkyBhSQauR1sUyFwIcNKLa/ics…
Zoom
Meetinghttps://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34.1Meeting
ID: 935 5786 3987Passcode: 939141---One tap
mobile+12532158782,,93557863987# US (Tacoma)+13017158592,,93557863987# US
(Washington DC)---Dial by your location• +1 253 215 8782 US (Tacoma)• +1
301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1
312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623
US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558
8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128
US (San Jose)• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US•
833 548 0276 US Toll-free• 833 548 0282 US Toll-free• 833 928 4608 US
Toll-free• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853
5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 935 5786 3987Find
your local number: https://linaro-org.zoom.us/u/adoz9mILli
Guests
tf-a(a)lists.trustedfirmware.org
qwandor(a)google.com
praan(a)google.com
jeremimiller(a)google.com
jagdish.gediya(a)linaro.org
Hi,
On Dec 11th in the TF-A Tech Forum at 4.00pm UK, Soby Mathew will present a design update on TF-RMM Live Firmware Activation:
This presentation describes the revised TF-RMM Low-VA MMU and global-runtime-data design required to support Live Firmware Activation (LFA). Compared to the earlier approach (outlined in the TFA Tech Forum session on 12-Jun-2025 [1] ), which assumed mostly fixed boot time mappings and per-platform handcrafted Low-VA contexts, the new design is driven by several changes in RMM specification: RMM must now support runtime mapping/unmapping of PAs for RMM objects like struct granule , reuse those dynamic mappings across LFA transitions. These PAs can come either from NS world at runtime or EL3 reservation from RMM carveout.
In order to migrate Stage 1 dynamic mappings across LFA instances, RMM needs to reduce dependence on platform-specific MMU setup, and provide a structured framework for allocating, versioning and migrating global runtime data. The Stage 1 Low-VA is therefore split into static and dynamic regions managed by the common xlat layer. The detailed design is captured in the TF-RMM wiki RFC “TF-RMM Live Firmware Activation [2]” and builds on the initial design presented in the TFA Tech Forum session on 12-Jun-2025 [1] :
[1] Previous LFA discussion: https://github.com/TF-RMM/tf-rmm/wiki/TFA-Tech-Forum-Presentations
[2] https://github.com/TF-RMM/tf-rmm/wiki/RFC:-TF%E2%80%90RMM-Live-Firmware-Act…
Regards,
Olivier.
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#id1https://trustedfirmware-a-tests.readthedocs.io/en/v2.14.0/change-log.html#v…https://hafnium.readthedocs.io/en/v2.14.0/change-log.html#id1https://tf-rmm.readthedocs.io/en/tf-rmm-v0.8.0/about/change-log.html#v0-8-0https://git.trustedfirmware.org/plugins/gitiles/TS/trusted-services/+/refs/…
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
FYI
From: Saheer Babu via Tf-openci <tf-openci(a)lists.trustedfirmware.org>
Date: Wednesday, 10 September 2025 at 15:17
To: tf-openci(a)lists.trustedfirmware.org <tf-openci(a)lists.trustedfirmware.org>
Subject: [Tf-openci] CI infrastructure scheduled maintenance: 12th Sep 2025
Hi all,
We will be performing upgrade of the clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Friday, 12th Sep 2025 at 16:00 GMT+1.
During this maintenance window, both services will be unavailable for approximately 4 hours.
A follow-up email will be sent once the services are fully restored.
Best regards,
Saheer
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
Tf-openci mailing list -- tf-openci(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-openci-leave(a)lists.trustedfirmware.org
Hi,
Sona Rebecca Mathew will present on the TF-RMM ID registers management scheme at the TF-A Tech Forum tomorrow. Her presentation is expected to take place during the second half of the one-hour session.
Abstract:
* Earlier RMM directly read ID registers, creating a dependency on EL3 revisions to enable features forcing a version compatibility between the two.
* New approach: EL3 capabilities are queried via an SMC call and RMM now uses cached ID register copies populated at cold boot. Includes forward-looking support for FEAT_IDTE3 in TF-A.
For meeting details, please refer to the TF-A Tech Forum email here : https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
Best Regards
Soby Mathew
Hi Everyone,
We've merged the final batch of outstanding patches for Alp-12-based DA foundation support in RMM: TF-RMM Commit bd2eb59<https://github.com/TF-RMM/tf-rmm/commit/bd2eb596ca0739c8051badefde34993e24f…>
This completes the fourth and final merge in the series, incorporating support for DVSEC and IDE key programming. With this, the refactoring of the Alp-12 branch to the EL0 app framework is now complete.
(Some quick stats: over 60 patches and >13K lines of code changed.)
While the current base support has several limitations that we plan to address in the coming months including:
1. Initial SMMU Stage 2 driver
2. Updated IDE key programming flow
3. Alp-16 migration groundwork
4. Multi PDEV/VDEV support
5. Validation of PDEV , VDEV params and improved testing from TFTF.
With the base DA support now in place, RMM is ready to accept contributions to further improve Device assignment support.
Best Regards
Soby Mathew
Hi Everyone
We have pushed a Design document for TF-RMM Live Firmware Activation for wider discussion : https://github.com/TF-RMM/tf-rmm/wiki/RFC:-TF‐RMM-Live-Firmware-Activation
An initial implementation of the design is available for review here : https://review.trustedfirmware.org/q/topic:"rmm-lfa<https://review.trustedfirmware.org/q/topic:%22rmm-lfa>"
This patch series had to undergo a lot of design changes mainly around Stage 1 xlat management. Some of the changes were done anticipating upcoming feature like Flexible memory management in RMM specification.
We hope to schedule a separate design review session discussing the same. Please let us know of feedback or comments in the meantime.
Best Regards
Soby Mathew
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 Everyone,
The FEAT_MEC enablement patches have now been merged into RMM:
https://github.com/TF-RMM/tf-rmm/commit/8819a19d048b273438690954c151c8333db…
This marks the culmination of several months of work.
The patch series went through two major rewrites as we experimented with different implementation approaches. This also led to a re-design of the delegate scrub flow in RMM, which was merged earlier as a precursor to this work.
We also received design inputs from @Raghu K , which resulted in more fine-grained programming of the MEC registers. In addition, two extra hardening methods were implemented based on this feedback. These can be enabled via the RMM_MEM_SCRUB_METHOD build flag.
In the coming days, we plan to profile the three different scrub methods to determine a more suitable default.
The FEAT_MEC design in RMM and rationale for the hardening is explained here:
https://github.com/TF-RMM/tf-rmm/wiki/RFC:-FEAT_MEC-Design-in-RMM
As usual, please let us know if you find any issues.
Best Regards
Soby Mathew
Hi Everyone,
The Planes patch stack has been merged!
https://github.com/TF-RMM/tf-rmm/commit/d2f72c4ec9e091b8bb12b53fe2bc022351f… .
This update includes more than 15K lines of code changes. Some patches went through 100+ revisions over the last 1.5 year, and we've added significant new framework support as well as test cases to TFTF. As with any large integration, we expect to encounter some issues in the coming days, which we'll be addressing . We already have a list of improvements and fixups identified, and more TFTF tests will follow.
In the meantime, please let us know if you come across any issues or have suggestions for improvements.
Best Regards
Soby Mathew
Hi Everyone,
I'm pleased to announce that Raghupathy K has joined the group of maintainers for TF-RMM. This decision reflects Raghu's significant contributions to the project, including code reviews, design discussions and feature contributions over the past couple of years.
The maintainers file has been updated accordingly : https://github.com/TF-RMM/tf-rmm/blob/main/docs/about/maintainers.rst
Best regards,
Soby Mathew (on behalf of all TF-RMM maintainers)
Hi Everyone,
We merged the new ID sysreg management scheme into RMM today.
Background:
Previously, RMM directly read the ID_xxx sysregs to determine hardware capabilities before enabling features in the Realm world. This approach implicitly required EL3 to enable the feature first, creating a revision lockstep between RMM and the EL3 firmware.
New Scheme:
With the updated ID register management, EL3 capabilities are queried via the SMCCC_ARCH_FEATURE_AVAILABILITY call. RMM now maintains a shadow copy of the ID sysregs in memory (referred to in the codebase as the cached_ID reg). This cached copy is populated during cold boot, and RMM will only access the cached ID regs at runtime.
The design also anticipates future support for FEAT_IDTE3 in TF-A.
Benefits:
* Sanitized Realm view of ID regs: Instead of using a "disallow" mask, RMM now uses an "allow" mask to define what features are exposed.,
* Forward compatibility: Older RMM versions running on newer architectures will not expose previously RES0 fields to realms, thanks to the "allow" mask approach.,
* Feature discrepancy handling: In the future, RMM could detect CPU feature differences and react accordingly.,
* Live migration readiness: This scheme may also help when handling feature differences in live migration scenarios.,
The merge commit can be found here : https://github.com/TF-RMM/tf-rmm/commit/4a9d781892074e8997e73411cfe5a220223…
The current CI tests are passing. There is a chance that we may not have exposed all the bitfields needed, but if you find any failure due to missing ID features, please let us know.
Please be aware that outstanding patches may need to be rebased on top of this.
Best Regards
Soby Mathew
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,
Ok. It seems to be some effect of memory management of kernel and I don't know details about that. Otherwise, your FVP/QEMU setup seems fine.
Best Regards
Soby Mathew
From: neptune <awsomered(a)foxmail.com>
Sent: Wednesday, August 6, 2025 10:49 AM
To: Soby Mathew <Soby.Mathew(a)arm.com>
Subject: Re:[tf-rmm] Re: question about rmm
test both on qemu and fvp.When use fvp, I follow the step of cca-3world in shrinkwrap but with da support.But i don't think da will cause this.And when use qemu, I follow the step in
Building+an+RME+stack+for+QEMU<https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+an…> without da support.
And then, what's strange is that when i use allocated memory,it will cause gpf.Like this.
static void *allocate_granule(void) {
void *page = (void *)__get_free_pages(GFP_KERNEL, 0); // Allocate one page
if (!page) {
printk(KERN_ERR "Failed to allocate granule\n");
}
return page;
}
int create_realm(void)
{
struct smc_result result;
int ret = 10;
void* tmp = allocate_granule();
if (!tmp) {
pr_err("Failed to allocate tmp buffer\n");
return -ENOMEM;
}
memset(tmp, 0, PAGE_SIZE);
memcpy(tmp, (void *)realm_start, PAGE_SIZE);
host_rmi_granule_delegate(virt_to_phys(tmp), &result);
CHECK_RMI_RESULT();
pr_info("host_rmi_granule_delegate %p\n", (uintptr_t)virt_to_phys(tmp));
char dst[9] = {0};
memcpy(dst, tmp, 8);
pr_info("memcpy done %x\n", *(uint64_t *)dst);
host_rmi_granule_undelegate(virt_to_phys(tmp), &result);
CHECK_RMI_RESULT();
pr_info("host_rmi_granule_undelegate done\n");
return 0;
}
------------------ Original ------------------
From: "Soby Mathew" <tf-rmm(a)lists.trustedfirmware.org<mailto:tf-rmm@lists.trustedfirmware.org>>;
Date: Wed, Aug 6, 2025 04:38 PM
To: "neptune"<awsomered(a)foxmail.com<mailto:awsomered@foxmail.com>>;"tf-rmm"<tf-rmm(a)lists.trustedfirmware.org<mailto:tf-rmm@lists.trustedfirmware.org>>;
Cc: "nd"<nd(a)arm.com<mailto:nd@arm.com>>;
Subject: [tf-rmm] Re: question about rmm
Hi Neptune
You are right, I would have expected a Granule protection fault (GPF) when accessing a physical address delegated to realm world. It is difficult to say why, without further information about the platform , EL3 firmware used etc. If the platform is FVP, then the FVP cmd line options would need to be verified.
Would recommend reproducing your test in a shrinkwrap setup https://shrinkwrap.docs.arm.com/en/latest/userguide/configstore/cca-3world.… and see the behavior.
Best Regards
Soby Mathew
From: neptune via tf-rmm <tf-rmm(a)lists.trustedfirmware.org<mailto:tf-rmm@lists.trustedfirmware.org>>
Sent: Tuesday, August 5, 2025 2:02 PM
To: tf-rmm <tf-rmm(a)lists.trustedfirmware.org<mailto:tf-rmm@lists.trustedfirmware.org>>
Subject: [tf-rmm] question about rmm
I'm doing some tests on tf-rmm while found something interesting.
Why this code can execute without error?This code is part of a driver.
__attribute__((aligned(4096)))
static int realm_start(void)
{
return 11;
}
int create_realm(void)
{
struct smc_result result;
int ret = 10;
flush_cache_all();
flush_tlb_all();
isb();
host_rmi_granule_delegate(virt_to_phys(realm_start), &result);
CHECK_RMI_RESULT();
pr_info("host_rmi_granule_delegate %lx\n", (uintptr_t)virt_to_phys(realm_start));
flush_cache_all();
flush_tlb_all();
isb();
ret = realm_start();
pr_info("run realm start %d\n", ret);
char dst[9] = {0};
memcpy(dst, realm_start, 8);
pr_info("memcpy done %x\n", *(uint64_t *)dst);
host_rmi_granule_undelegate(virt_to_phys(realm_start), &result);
CHECK_RMI_RESULT();
pr_info("host_rmi_granule_undelegate done\n");
return 0;
}
Here is the output of linux and tf-rmm
[ 743.248076] realm: loading out-of-tree module taints kernel.
[ 743.260986] realm_create: Module loaded
[ 743.261778] SMC_GRANULE_DELEGATE: addr = 0xeda70000 eda70000
[ 743.265428] host_rmi_granule_delegate eda70000
[ 743.266110] run realm start 11
[ 743.266581] memcpy done 52800160
[ 743.268005] host_rmi_granule_undelegate done
SMC_RMI_GRANULE_DELEGATE eda70000 > RMI_SUCCESS
SMC_RMI_GRANULE_UNDELEGATE eda70000 > RMI_SUCCESS
Hi Everyone,
We are planning a major change to granule scub flow in TF-RMM. This is done mainly in preparation for supporting FEAT_MEC. When FEAT_MEC is present, granules must be zeroed with the appropriate MECID programmed. Previously, RMM performed scrubbing (zeroing) during the transition to the DELEGATED state. However, for FEAT_MEC, granules must be initialized with the correct MECID when they transition into a Realm. The new granule transition flow improves efficiency and eliminates redundant operations while preserving security guarantees.
Key changes:
* Scrubbing now occurs during transitions from DELEGATED to another state, instead of to DELEGATED.,
* This ensures that data is sanitized before a granule is either: Assigned to a new Realm, or reclaimed by the NS Host.,
All RMI_*_CREATE() APIs, which transition granules from DELEGATED to Realm states, and RMI_UNDELEGATE() have been updated to correctly initialize or zero the buffer as needed.
Performance improvements:
* Redundant zeroing previously done during RMI_DATA_CREATE() and RMI_RTT_CREATE() is eliminated.,
* When FEAT_MEC is enabled, scrubbing before initialization (for new Realm usage) is removed, further improving efficiency.,
The patch is here : https://review.trustedfirmware.org/c/TF-RMM/tf-rmm/+/39096/22 . Please let us know if you see some issues with the change.
The FEAT_MEC patch series is available for review here : https://review.trustedfirmware.org/c/TF-RMM/tf-rmm/+/35509/9
Best Regards
Soby Mathew
Hello Jaehyeon,
We are still working on providing support for FEAT_MEC on RMM. More patches are coming in the next few weeks.
In order to run the current patches with MEC enabled, you have to set some more parameters for the FVP:
-C bp.mpe.enable=1 \
-C bp.mpe.block_size_in_bytes=4096 \
-C bp.mpe.corruption_strategy=0 \
-C bp.mpe.ignore_mecid=0 \
-C bp.mpe.output_attributes_parameter_of_core=ExtendedID[62:55]=MPAM_PMG \
-C bp.mpe.output_attributes_parameter_of_core=ExtendedID[38]=MPAM_SP[0] \
-C bp.mpe.output_attributes_parameter_of_core=ExtendedID[37]=MPAM_SP[1] \
-C bp.mpe.output_attributes_parameter_of_core=UserFlags[31:16]=MECID \
-C bp.mpe.non_secure_pas_enc_key=34 \
-C bp.mpe.realm_pas_enc_key=136 \
-C bp.mpe.root_pas_enc_key=68 \
-C bp.mpe.secure_pas_enc_key=17 \
-C cluster0.mec_support_level=2 \
-C cluster0.rme_mecid_width=16 \
-C cluster1.mec_support_level=2 \
-C cluster1.rme_mecid_width=16 \
I have attached a Shrinkwrap overlay in case you want to use it instead.
Let me know if you have any questions.
All the best,
Juan Pablo
--
From: Jaehyeon Lee
Sent: 23 Jun 2025 6:07 a.m
To: tf-rmm(a)lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-rmm@lists.trustedfirmwar…>
Subject: [tf-rmm] Questions regarding ARM CCA MEC feature
Hello tf-rmm group,
I'm currently conducting research on the MEC (Memory Encryption Context) feature for sharing memory pages across multiple realms, and I'm interested in testing and potentially extending this functionality w/ new use-cases.
I noticed that there are mec-proto branches available across the TF-A repositories, including rmm, linux, kvmtool, and tf-a, specifically for the CCA memory encryption context. However, I've been unable to successfully launch a system using these branches on the FVP models.
Is there a reference setup or guidance available for bringing up a MEC-enabled Realm environment, similar to the DA branches discussed here<https://lists.trustedfirmware.org/archives/list/tf-rmm@lists.trustedfirmwar…>?
Also, extending MEC feature to allow sharing pages across multiple realms are feasible w/ current hardware (RME w/ MPE) spec? w/ utilizing MEC_STATE_SHARED state in RMM 1.1 alp14 spec.
Thank you,
Jaehyeon Lee
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello tf-rmm group,
I'm currently conducting research on the MEC (Memory Encryption Context) feature for sharing memory pages across multiple realms, and I'm interested in testing and potentially extending this functionality w/ new use-cases.
I noticed that there are mec-proto branches available across the TF-A repositories, including rmm, linux, kvmtool, and tf-a, specifically for the CCA memory encryption context. However, I've been unable to successfully launch a system using these branches on the FVP models.
Is there a reference setup or guidance available for bringing up a MEC-enabled Realm environment, similar to the DA branches discussed here<https://lists.trustedfirmware.org/archives/list/tf-rmm@lists.trustedfirmwar…>?
Also, extending MEC feature to allow sharing pages across multiple realms are feasible w/ current hardware (RME w/ MPE) spec? w/ utilizing MEC_STATE_SHARED state in RMM 1.1 alp14 spec.
Thank you,
Jaehyeon Lee
Hi, On June 12th 2025, the TF-A Tech forum will take place at 4.00pm UK
with the following topic: TF-RMM live activation design discussion
Presenters: Andre Przywara Soby Mathew Manish Badarkhe In this meeting, we
aim to discuss the details of live firmware activation for TF-RMM. The key
topics will include: * Design details of TF-RMM live activation * Rationale
for EL3-RMM communication changes: We will explain the motivation behind
the proposed changes to the communication mechanism between EL3 and RMM
which simplifies internal state migration for LFA, enables sharing of the
state across RMM instances that are live-activated, supports localized
per-CPU allocations for NUMA and multi-chip configurations, decouples the
RMM binary from platform-specifics. * LFA SMC Implementation in EL3: We
will also provide an overview of the LFA SMC implementation at EL3.
Regards, Olivier.
TF-A Tech Forum
Thursday Jun 12, 2025 ⋅ 5pm – 6pm
Central European Time - Paris
Location
https://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34…https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9355786…
Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-A
Tech ForumTime: May 15, 2025 02:00 PM London Every 2 weeks on Thu,
78 occurrence(s)Please download and import the following iCalendar (.ics)
files to your calendar
system.Weekly: https://linaro-org.zoom.us/meeting/tJcocu6gqDgjEtOkyBhSQauR1sUyFwIcNKLa/ics…
Zoom
Meetinghttps://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34.1Meeting
ID: 935 5786 3987Passcode: 939141---One tap
mobile+12532158782,,93557863987# US (Tacoma)+13017158592,,93557863987# US
(Washington DC)---Dial by your location• +1 253 215 8782 US (Tacoma)• +1
301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1
312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623
US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558
8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128
US (San Jose)• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US•
833 548 0276 US Toll-free• 833 548 0282 US Toll-free• 833 928 4608 US
Toll-free• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853
5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 935 5786 3987Find
your local number: https://linaro-org.zoom.us/u/adoz9mILli
Guests
tf-a(a)lists.trustedfirmware.org
Hi Manoj,
Hi, Yes, your understanding is correct, according to the reference manual, if HaveEL(EL3) and MPAM3_EL3.TRAPLOWER == 1,
then any EL2 access to MPAMIDR_EL1 is trapped to EL3 (AArch64.SystemAccessTrap(EL3, 0x18)).
The upstream TF-A master disables this bit :
https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/…
Currently there is a strong dependency between feature enablement in EL3 and RMM accessing the registers.
We have some patches in progress for RMM to discover feature enablement status in EL3 and only proceed with register access (like MPAM) when explicitly permitted.
Link to the patches for your reference:
https://review.trustedfirmware.org/q/topic:%22sm/revlock%22
Thanks
-Sona
Manoj Ekbote wrote:
> Hi,
> I am trying to run TF-RMM and there's an exception while reading the MPAMIDR_EL1 register in rmm_arch_init().
> if (is_feat_mpam_present()) {
> unsigned long mpamidr_el1 = read_mpamidr_el1();
> ..
> }
> The condition to access MPAMIDR_EL1 is:
> elsif PSTATE.EL == EL2 then
> if HaveEL(EL3) && EL3SDDUndefPriority() && MPAM3_EL3.TRAPLOWER == '1' then
> UNDEFINED;
> elsif HaveEL(EL3) && MPAM3_EL3.TRAPLOWER == '1' then
> if EL3SDDUndef() then
> UNDEFINED;
> else
> AArch64.SystemAccessTrap(EL3, 0x18);
> else
> X[t, 64] = MPAMIDR_EL1;
> I am running TF-A before TF-RMM, so the default value of 1 in MPAM3_EL3.TRAPLOWER forces all accesses to MPAMIDR_EL1 to be trapped to EL3.
> And the read in TF-RMM then causes an exception.
> But there's no handler for the trap in TF-RMM that can forward the read to EL3.
> Is my understanding right that the code to handle the trap is missing in RMM?
> Thanks,
> Manoj
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi,
I am trying to run TF-RMM and there's an exception while reading the MPAMIDR_EL1 register in rmm_arch_init().
if (is_feat_mpam_present()) {
unsigned long mpamidr_el1 = read_mpamidr_el1();
..
}
The condition to access MPAMIDR_EL1 is:
elsif PSTATE.EL == EL2 then
if HaveEL(EL3) && EL3SDDUndefPriority() && MPAM3_EL3.TRAPLOWER == '1' then
UNDEFINED;
elsif HaveEL(EL3) && MPAM3_EL3.TRAPLOWER == '1' then
if EL3SDDUndef() then
UNDEFINED;
else
AArch64.SystemAccessTrap(EL3, 0x18);
else
X[t, 64] = MPAMIDR_EL1;
I am running TF-A before TF-RMM, so the default value of 1 in MPAM3_EL3.TRAPLOWER forces all accesses to MPAMIDR_EL1 to be trapped to EL3.
And the read in TF-RMM then causes an exception.
But there's no handler for the trap in TF-RMM that can forward the read to EL3.
Is my understanding right that the code to handle the trap is missing in RMM?
Thanks,
Manoj
Hello tf-rmm group,
I think i found several vulnerabilities in tf-rmm code, where should i report it. I don't see ways to report vulnerabilities in your github repositories security page or docs. After the vulnerability is confirmed, can you assign a CVE-ID for it?
--
Best Regards
Haiwang Wang
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.
This event has been canceled.
TF-A Tech Forum
Thursday 23 Mar 2023 ⋅ 12pm – 1pm
Eastern Time - Toronto
Discussion Topic: RAS Refactoring Presented by: Manish Pandey and Soby
MathewTopics to be discussed 1. Introduction to philosophies of handling
RAS errors(FFH/KFH) 2. Discussing exceptions caused by synchronization
barriers at execption boundries 3. Refactoring and enhancements in
TF-A(along with various build macros) 4. Tests introduced 5. Future
work----------------We run an open technical forum call for anyone to
participate and it is not restricted to Trusted Firmware project members.
It will operate under the guidance of the TF TSC. Feel free to forward this
invite to colleagues. Invites are via the TF-A mailing list and also
published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
Don Harbin
bpeckham(a)google.com
moritzf(a)google.com
kh3195(a)columbia.edu
tf-a(a)lists.trustedfirmware.org
tf-rmm(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
This event has been canceled.
TF-A Tech Forum
Thursday 1 Jun 2023 ⋅ 11am – 12pm
Eastern Time - Toronto
Topic: SVE Enablement in RMM for Realms. Presenter: Arunachalam
GanapathyOverview: This discussion will cover the design and implementation
details on how SVE and FP/AdvSIMD state of Non secure world and Realms are
managed by RMM.=====================We run an open technical forum call for
anyone to participate and it is not restricted to Trusted Firmware project
members. It will operate under the guidance of the TF TSC. Feel free to
forward this invite to colleagues. Invites are via the TF-A mailing list
and also published on the Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558 8656 US (New
York) +1 669 900 9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
Don Harbin
tf-a(a)lists.trustedfirmware.org
tf-rmm(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
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 Everyone
As discussed in TF-A Tech Forum in January, RMM is introducing EL0 app support which is deprivileging parts of RMM to run at EL0. This is done mainly for security but it also enables other capabilities as discussed in the presentation : https://github.com/TF-RMM/tf-rmm/wiki/TFA-Tech-Forum-Presentations
The patch stack can be accessed here : https://review.trustedfirmware.org/c/TF-RMM/tf-rmm/+/36886/1 . This is complex functionality touching many parts of RMM. The merge is likely to affect outstanding patches as they would have merge conflict on rebase. We have identified further enhancements and hardening which can be done to improve the security and performance of the EL0 app framework . These will be taken up after the merge.
We are hoping to merge this patch stack early next week so that any issues identified can be fixed up prior to TF-A v2.13 release planned for next month. The design document is still undergoing review and will be progressed after the merge of functionality.
Best Regards
Soby Mathew
+TF-RMM ML
________________________________
From: Google Calendar <calendar-notification(a)google.com> on behalf of Olivier Deprez <olivier.deprez(a)arm.com>
Sent: 17 January 2025 08:46
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; Olivier Deprez <Olivier.Deprez(a)arm.com>
Subject: TF-A Tech Forum - Jan 23rd 2025 - RMM design of EL0 applications support
Hi,
On Jan 23rd 2025, in the TF-A Tech forum, Mate Toth-Pal and Soby Mathew will present the RMM design of EL0 applications support.
The TF-A Tech forum is a regular open forum for anyone from the open source community to participate. Feel free to reach if you have a topic you'd want to present. It can be a design review with slides, walking through RFC patches, or more generic discussion around open source projects.
Regards,
Olivier.
TF-A Tech Forum
Thursday Jan 23, 2025 ⋅ 5pm – 6pm (Central European Time - Paris)
We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.
Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website.
Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…>
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvd…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmy%2Ftruste…>
One tap mobile
+16465588656,,9159704974# US (New York)
+16699009128,,9159704974# US (San Jose)
Dial by your location
+1 646 558 8656 US (New York)
+1 669 900 9128 US (San Jose)
877 853 5247 US Toll-free
888 788 0099 US Toll-free
Meeting ID: 915 970 4974
Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…>
Guests
tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
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/
Hi Everyone,
In order to facilitate development for Device Assignment tests for RME-DA, we have added MbedTLS repo as a submodule dependency to tf-a-tests. The merge commit can be found here : https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/3e72cd…
The patch is done in such a way that existing build of TF-A-Tests or Test run is not affected due to the additional dependency. Only tests which depend on MbedTLS will be affected in that they will either be skipped or fail at runtime due to the missing dependency. Also, the change allows to use the config `MBEDTLS_DIR` to point to a MbedTLS directory outside the tf-a-tests source tree. This aligns with the TF-A mechanism for MbedTLS dependancy in case the submodule mechanism is not preferred.
We expect existing CI and testing infrastructure to be unaffected by this change. Please let us know if you have any comments.
Best Regards
Soby Mathew
Hi Everyone
We are planning to change how TF-RMM clones and updates the submodule dependencies. The usual practice is to specify the `recursive` option to git clone of the project. This works well when the submodules themselves do not have dependencies. For some dependent repositories like libspdm, there are further dependencies like openssl, cmocka which are not used in the RMM context. Hence specifying the specifying the `recursive` option is not the ideal solution especially when RMM is deployed in Continuous integration solutions. The above issue was worked around in RMM by fetching libspdm within the build context but this was also not ideal as it kept the libspdm outside the git submodules framework and the git fetch was done every time the project was rebuilt.
To solve this, we are proposing to move the management of the submodules into the build system and away from the user. Specifically, during configuration phase of the project, cmake will issue `git submodule update --init --depth 1`.
This means that the user will not be responsible for syncing the submodules anymore and the build system will take of this. This also ties in with the patching method of the build system as a particular SHA can be ensured before the patch is applied.
The patch can be found here : https://review.trustedfirmware.org/c/TF-RMM/tf-rmm/+/33512
Any rebase of the project which updates the submodules will now be transparently applied without the user having to update the submodules manually.
We think that we will have more dependent submodules for TF-RMM in the future and it is better to script this within the build system. This change should not break any of the existing CI systems as it is backward compatible, but it may become a little inefficient if the `recursive` option is specified as there will be unnecessary git repositories fetched.
Please let us know if any comments.
Best Regards
Soby Mathew
hello tf-rmm group,
Recently I'm learning ARM CCA.But I have trouble running the latest version TF-RMM.It failed at runtime/ core/ init.c/ in func rmm_arch_init.When try to do write_hcrx_el2 action it paniced.So it looks like the FVP doesn't have the hcrx_el2 register.I'm using the FVP_Base_RevC-2xAEMvA_11.27_19. It's the latest version in the arm's offical website.The tf-rmm-v0.5.0 works fine.So I'm wondering how do you test latest version TF-RMM.It would be appreciated if you could reply.
Best,
Wang.
+ 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,
Please have a look at virtio-mem which provides memory hotplug for VMs. It
is available in Linux, QEMU, cloud-hypervisor and libvirt:
https://libvirt.org/kbase/memorydevices.html#virtio-mem-model
Another reason to use virtio-mem rather than ACPI memory hotplug is to
keep complexity out of ACPI tables, in order to simplify remote
attestation which requires measuring or verifying the firmware tables.
For example running QEMU with the following allows to hotplug 4G of memory
to the VM:
-m 512M,maxmem=1T
-object memory-backend-ram,id=mem0,size=4G
-device virtio-mem-pci,id=vm0,memdev=mem0,node=0
Then at runtime QEMU monitor can plug and unplug memory:
(qemu) qom-get vm0 size
(qemu) qom-set vm0 requested-size 1G
(qemu) qom-set vm0 requested-size 0
This works for a Realm VM, with a small change to the Linux guest:
https://jpbrucker.net/git/linux/commit/?h=cca/v4-hotplug&id=6b8768385fa464a…
(I'm not sure it's correct yet but may be worth adding to the initial guest
support.)
The host adds memory to the guest with
RMI_GRANULE_DELEGATE+RMI_DATA_CREATE_UNKNOWN, and removes it with
RMI_DATA_DESTROY+RMI_GRANULE_UNDELEGATE which ensures that the pages are
wiped before being returned to the host.
Virtual device hotplug works out of the box for a Realm VM. The VM needs
to have root ports allowing hotplug (see
https://www.libvirt.org/pci-hotplug.html#aarch64-architecture ), and the
guest kernel must have PCIe hotplug enabled. For example this adds a root
port in QEMU:
-device pcie-root-port,chassis=1,id=pcie.1,bus=pcie.0
Then in the monitor add a virtio-net device:
(qemu) netdev_add user,id=net1
(qemu) device_add virtio-net-pci,netdev=net1,bus=pcie.1,id=hp0
[ 300.003234] pcieport 0000:00:03.0: pciehp: Slot(0): Button press: will power on in 5 sec
...
[ 300.798772] virtio-pci 0000:01:00.0: enabling device (0000 -> 0002)
# lspci
01:00.0 Ethernet controller: Red Hat, Inc. Virtio 1.0 network device (rev 01)
And remove it:
(qemu) device_del hp0
The security model of hotplug is equivalent to regular PCI support in a
Realm: the guest should only interact with devices whose driver has been
hardened against untrusted hosts, and with devices authenticated via
CMA-SPDM.
Thanks,
Jean
Cloud vendors hope that cloud servers have hot-plug capabilities for CPU, memory, and devices. In confidential virtual machine scenarios, the measurement values will change after hot-plug , and rmi_data_create needs to be called to dynamically update the device tree information. Please consult CCA's plan for the hot-plug capability , and under the security model of confidential virtual machines, should the hot-plug capability of confidential virtual machines be supported?
Hi all,
I am working with FVP (Base RevC AEM) and arm integration solution (https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs…). I want to measure the overhead of a target ML workload between a realm VM and normal world VM. Both VMs are created by this command:
nice -n -20 taskset -c 1 lkvm run --realm -c 1 -m 350 -k /root/VM_image/Image -i /root/VM_image/VM-fs.cpio --irqchip=gicv3
the target workload code and data is envisioned into the VM-fs.cpio. I also use GenericTrace to measure the number of instructions executed by core 1 (taskset -c 1 indicates that the VM process should be only given to core one). I use ToggleMTIPlugin to enable/disable tracing at particular points (at the beginning and end of the target workload inside the VM). What I am experiencing is that the numbers in normal world VM are very stable (271 millions) but, the numbers in the realm VM are very different between different runs of realm VM (from 314 to 463 and even 7671 millions!!!). I do all measurements in the same run of FVP in which I create a NW VM and run the target workload, then I destroy it and create a realm VM, run the target workload and destroy it while I repeat this steps several times and then terminates the FVP. I guess something in between the path from the realm to hypervisor makes the numbers unstable (either RMM or secure monitor). Have you ever seen such a problem and worked around measuring number of instructions for the realm workloads?
Thanks,
Sina
Hi All,
We are pleased to announce the formal release of Trusted Firmware-A version 2.10 bundle of project deliverables.
This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, RMM and TF-A OpenCI Scripts/Jobs 2.10 releases involving the tagging of multiple repositories.
These went live on 22nd November 2023.
Please find references to tags and change logs at the end of this email.
Many thanks to the community for the active engagement in delivering this release!
Notable Features of the Version 2.10 Release are as follows:
TF-A/EL3 Root World
* New Features:
* Firmware handoff library support
* Improvements to BL31 runtime exception handling
* Context management refactoring for RME/4 worlds
* Gelas, Nevis & Travis CPUs support
* V8.9 features enabled (FEAT_ HAFT, RPRFM, LRCPC3, MTE_PERM)
TF-A Boot BL1/BL2
* New Features
* Trusted Boot support for ECDSA (Elliptic Curve Digital Signature Algorithm)
* Migrated to PSA crypto API’s
* Improved the GUID Partition Table (GPT) parser.
* Various security Improvements and threat Model updates for ARM CCA
* Signer id extraction Implementation
Hafnium/SEL2 SPM
* New Features:
* FF-A v1.2: FFA_YIELD with time-out; EL3 SPMDs LSPs communication; memory sharing updates.
* Memory region relative base address field support in SP manifests.
* Interrupt re-configuration hypervisor calls.
* Memory management: S2 PT NS/S IPA split
* SMCCCv1.2+ compliance fixes.
* Feature parity test improvements, EL3 SPMC and Hafnium (S-EL2 SPMC)
TF-RMM/REL2
* New Feature/Support
* Fenimore v1.0 EAC5 aligned implementation.
* TFTF Enhancements for RME testing
* Initial CBMC support
* NS SME support in RMM
* BTI support for RMM
Errata
* Errata implemented (1xCortex-X2/ Matterhorn-ELP, 1xCortex-A710/Matterhorn, 1xNeoverse N2/Perseus, 2xNeoverse V2/Demeter, Makalu ELP/Cortex X3, Klein/Cortex-A510)
* Fix some minor defects with version in a few errata that applies for some follow up revisions of the CPUs. (Neoverse V1, Cortex-X2, Cortex-A710)
TF-A Tests
* Core
* Added errata management firmware interface tests.
* Added firmware handoff tests.
* Introduced RAS KFH support test.
* SPM/FF-A
* Support SMCCCv1.2 extended GP registers set.
* Test SMCCC compliance at the non-secure physical instance.
* Test secure eSPI interrupt handling.
* Test FF-A v1.2 FFA_PARTITION_INFO_GET_REGS interface.
* RMM
* Added FPU/SVE/SME tests
* Added multiple REC single CPU tests.
* Added PAuth support in Realms tests.
* Added PMU tests.
Platform Support
* New platforms added:
* Aspeed AST2700, NXP IMX93, Intel Agilex5, Nuvoton NPCM845x, QTI MDM9607, MSM8909, MSM8939, ST STM32MP2
Release tags across repositories:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.10https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.10https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/hafnium-job-configs.git/tag/?h=v2.10https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.4.0
Change logs:
https://trustedfirmware-a.readthedocs.io/en/v2.10/change-log.html#id1https://trustedfirmware-a-tests.readthedocs.io/en/v2.10/change-log.html#ver…https://hafnium.readthedocs.io/en/latest/change-log.html#v2-10https://tf-rmm.readthedocs.io/en/tf-rmm-v0.4.0/about/change-log.html#v0-4-0
Regards,
Olivier.
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.10 has an expected code freeze date of Nov, 7th 2023.
Refer to the Release Cadence section from TF-A documentation (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about…).
Closing out the release takes around 6-10 working days after the code freeze.
Preparations tasks for v2.10 release should start in coming month.
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 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.
Hi Everyone,
This Thursday , Shruti from TF-RMM team will discuss the following topics in TF-A Tech Forum :
1. Integration of CPPCheck in TF-RMM
* CPPCheck is an open-source static analyzer with addon MISRA checker. In this talk, we will discuss the CPPCheck integration in TF-RMM build system and demonstrate the same.
2. TF-A-Tests enhancements and testing for TF-RMM
* Discuss new enhancements in TF-A-Tests for Realm Payload tests including Creating, Loading & Running Realm Payload, testing multiple Rec’s and PSCI support for Realms. We will also cover some Test framework conventions and aspects of Stage2 Memory Management, Realm Memory Exception Model testing.
Best Regards
Soby Mathew
-----Original Appointment-----
From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>
Sent: Thursday, February 22, 2024 10:13 PM
To: Trusted Firmware Public Meetings; tf-a(a)lists.trustedfirmware.org; marek.bykowski(a)gmail.com; okash.khawaja(a)gmail.com
Subject: TF-A Tech Forum
When: 02 May 2024 16:00-17:00 Europe/London.
Where:
TF-A Tech Forum
We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this
This event has been updated with a note:
"Updating invite link"
Changed: description
Description
CHANGED
We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.
Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website.
Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…>
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvd…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmy%2Ftruste…>
One tap mobile
+16465588656,,9159704974# US (New York)
+16699009128,,9159704974# US (San Jose)
Dial by your location
+1 646 558 8656 US (New York)
+1 669 900 9128 US (San Jose)
877 853 5247 US Toll-free
888 788 0099 US Toll-free
Meeting ID: 915 970 4974
Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…>
When
Every 2 weeks from 9am to 10am on Thursday (Mountain Standard Time - Phoenix)
Guests
tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
marek.bykowski(a)gmail.com<mailto:marek.bykowski@gmail.com>
okash.khawaja(a)gmail.com<mailto:okash.khawaja@gmail.com>
View all guest info<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…>
RSVP for tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> for all events in this series
Yes<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…>
No<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…>
Maybe<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…>
More options<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…>
Invitation from Google Calendar<https://calendar.google.com/calendar/>
You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>
Hi All,
This is going out to all the primary TF maillists.
It's a gentle reminder that a TF Discord channel has been created for all
chat communications in the TF ecosystem. All TF participants are
encouraged to join.
Instructions on how to join can be found here:
https://www.trustedfirmware.org/faq/ <https://www.trustedfirmware.org/faq/>
[image: Screenshot 2024-04-17 at 7.08.01 AM.png]
Please let me know if you have any questions,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi, In the TF-A Tech Forum on Apr 18th at 4.00pm BST, Javier Almansa
Sobrino will present the topic of TF-RMM Stage-1 Memory management, by his
own words: "This week's TF-A Tech Forum will present the TF-RMM Stage 1
Memory Management, where we will discuss the design of the TF-RMM memory
space as well as some implementation details and future work." Regards,
Olivier.
TF-A Tech Forum
Thursday Apr 18, 2024 ⋅ 5pm – 6pm
Central European Time - Paris
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to colleagues.
Invites are via the TF-A mailing list and also published on the Trusted
Firmware website. Details are here:
https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
One tap mobile+16465588656,,9159704974# US (New
York)+16699009128,,9159704974# US (San Jose)Dial by your location +1
646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877
853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970
4974Find your local number: https://zoom.us/u/ad27hc6t7h
Guests
tf-a(a)lists.trustedfirmware.org
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
Hi all,
The TF-A Project runs an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It operates under the guidance of the TF TSC. The meeting is held fortnightly on thursdays @ 4PM BST.
This week's TF-A Tech Forum will present the TF-RMM Stage 1 Memory Management, where we will discuss the design of the TF-RMM memory space as well as some implementation details and future work.
Metting details with instructions on how to join will be provided on a follow-up email.
Best regards,
Javier