- tf-rmm - lists.trustedfirmware.org

Proposal to unify tf.org vulnerability referencing in NVD

by Sandrine Bailleux

Hi everyone, I am sending this email to all tf.org project mailing lists to ensure all maintainers are aware and on board regarding this matter. If you have any concerns or questions, please reply on tf.org Discord #general channel, where I'll create a thread, as I think it will be much easier than dealing with cross-mailing lists emails. Background When a security vulnerability is discovered in one of the trustedfirmware.org projects, it is common to request a "Common Vulnerabilities and Exposures" (CVE) number. This number uniquely references the issue, which can then be searched in the vulnerability databases. One of these databases is NIST's "National Vulnerability Database" (NVD): https://nvd.nist.gov<https://nvd.nist.gov/vuln/detail/CVE-2023-51712> Entering a specific CVE number in NVD search engine will allow you to easily find the details of a specific issue, for example: https://nvd.nist.gov/vuln/detail/CVE-2023-51712 However, sometimes one is not looking for a specific CVE number but rather wants to list all known vulnerabilities affecting a particular project. For this, one can use the Common Platform Enumerations (CPE) search engine: https://nvd.nist.gov/products/cpe/search CPE is a structured naming scheme that includes information like the vendor name, the project name, the version / tag, and so on. See https://nvd.nist.gov/products/cpe for more details. So for example, https://nvd.nist.gov/vuln/detail/CVE-2023-51712 referenced above has the following CPE: cpe:2.3:o:arm:trusted_firmware-m:*:*:*:*:*:*:*:* This basically means * CPE version 2.3 is in use * 'o is the type of project, in this case it stands for Operating Systems (which is probably the closest match for low-level code like TF-M) * 'arm' is the vendor (that is wrong, see below) * 'trusted_firmware-m' is the project name, Problem statement It appears that CPEs used in NVD to reference vulnerabilities in tf.org projects differ a lot across projects. For some projects, there's even multiple of them. Sometimes the vendor is "arm", sometimes it's "linaro", or something else. Some of the TF-A and MbedTLS maintainers have initiated discussions with NVD to get this simplified and unified, but it would make sense to align other tf.org projects as well. Proposal CPE naming rules are that the vendor name should the parent organization of the project. Thus the proposal would be for all tf.org projects to use "trustedfirmware" as the vendor name in their CPE. For example: cpe:2.3:o:trustedfirmware:trusted_firmware-m:*:*:*:*:*:*:*:* cpe:2.3:a:trustedfirmware:mbed_tls:*:*:*:*:*:*:*:* We're only proposing to change the vendor name here ; each project is then free to choose how they want the project name or the type of software project they want to encode there. Thanks for reading, Best regards, Sandrine Afsa

2 weeks, 1 day

1
1
0 0

FW: [TF-A] TF-A Tech Forum - Fuzzing TF-RMM Jun 11th 2026 4.00pm UK

by Soby Mathew

Forwarding to TF-RMM list. From: Google Calendar <calendar-notification(a)google.com> on behalf of Olivier Deprez via TF-A <tf-a(a)lists.trustedfirmware.org> Date: Monday, 8 June 2026 at 14:15 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; Olivier Deprez <Olivier.Deprez(a)arm.com> Subject: [TF-A] TF-A Tech Forum - Fuzzing TF-RMM Jun 11th 2026 4.00pm UK Hi, On Jun 11th 2026 4.00pm UK, Rustam Ismayilov will present the topic of TF-RMM fuzzing with the following agenda: Fuzzed Interfaces fake_host AFL++ seed generation statefull fuzzing Results and performance Limitations and planned improvements Regards, Olivier. TF-A Tech Forum Thursday Jun 11, 2026 ⋅ 5pm – 6pm (Central European Time - Paris) Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: TF-A Tech Forum Time: 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…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmeeting%2Ft…> Join Zoom Meeting https://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9355786…> Meeting ID: 935 5786 3987 Passcode: 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-free Meeting ID: 935 5786 3987 Find your local number: https://linaro-org.zoom.us/u/adoz9mILli<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2Fadoz9mI…> Location https://linaro-org.zoom.us/j/93557863987?pwd=56a1l8cBnetDTZ6eazHGaE1Ctk4W34… View map<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9355786…> Guests d82620130(a)gmail.com<mailto:d82620130@gmail.com> namyoon(a)google.com<mailto:namyoon@google.com> shaikadnanafrid(a)gmail.com<mailto:shaikadnanafrid@gmail.com> 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.

3 weeks, 1 day

1
0
0 0

CI infrastructure scheduled maintenance: 4th June Sep 2026

by Saheer Babu

Hi all, We will be upgrading Cloudbees CI and clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Wednesday, 3rd June 2025 at 16:00 GMT+1. During this maintenance window, both services will be unavailable for approximately 8 hours. A follow-up email will be sent once the services are fully restored. Best regards, Saheer [LOGO SMALL] Saheer Babu Principal Software Engineer CESW – Engineering Infrastructure

3 weeks, 6 days

1
2
0 0

Firmware-A v2.12 release rc0 tag

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

1 month

2
3
0 0

Firmware-A v2.15 release code freeze notification

by Harrison Mutai

Hi All, The next release of the Firmware-A bundle of projects tagged v2.15 has an expected code freeze date of 15/05/2026. 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.15 release preparation tasks are on-going and well progressed. 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 reminder and a matter of sharing CI resources, please launch CI jobs with care e.g.: * For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run). * For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack). * Carefully analyze results and fix the change if required, before launching new jobs on the same change. * If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued. Thanks & Regards, Harrison on behalf of the TF-A team

2 months

1
0
0 0

RMMv2.0 implementation plan for TF-RMM

by Soby Mathew

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

3 months

1
2
0 0

Realm guest stuck in IRQ loop

by Manoj Ekbote

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

4 months, 1 week

2
3
0 0

TF-A Tech Forum Dec 11th 4.00pm (UK) - TF-RMM Live Firmware Activation (design update)

by Olivier Deprez

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

6 months, 3 weeks

1
0
0 0

TF-A Tech Forum Dec 11th 4.00pm (UK) - TF-RMM Live Firmware Activation (design update)

by Olivier Deprez

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.

6 months, 3 weeks

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.

7 months, 1 week

1
0
0 0

Re: [Hafnium] Re: Gerrit scheduled maintenance: 8th November 8-12 UTC

by jerome.forissier＠linaro.org

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

7 months, 3 weeks

3
2
0 0

FW: CI infrastructure scheduled maintenance: 12th Sep 2025

by Joanna Farley

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

7 months, 3 weeks

2
3
0 0

TF-A Tech Forum on Thu Oct 30th 2025 4.00pm UK

by Soby Mathew

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

8 months

1
0
0 0

DA Alp-12 based patch stack merged

by 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

8 months

1
0
0 0

TF-RMM Live Firmware Activation Design

by 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

8 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

8 months, 2 weeks

2
3
0 0

FEAT_MEC support in RMM

by Soby Mathew

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

9 months, 1 week

1
0
0 0

RMM Planes feature update

by 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

9 months, 1 week

1
0
0 0

Welcoming Raghu as TF-RMM maintainer

by 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)

9 months, 2 weeks

1
0
0 0

ID sysreg mgmt scheme in RMM

by Soby Mathew

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

9 months, 3 weeks

1
0
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.

10 months, 2 weeks

1
0
0 0

Re: question about rmm

by Soby Mathew

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

10 months, 3 weeks

1
0
0 0

question about rmm

by neptune

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 doneSMC_RMI_GRANULE_DELEGATE eda70000 > RMI_SUCCESS SMC_RMI_GRANULE_UNDELEGATE eda70000 > RMI_SUCCESS

10 months, 4 weeks

2
1
0 0

FEAT_MEC and change to granule scrub flow

by Soby Mathew

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

11 months, 1 week

1
0
0 0

Re: Questions regarding ARM CCA MEC feature

by Juan Pablo Conde

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.

1 year

3
3
4 0