- tf-rmm - lists.trustedfirmware.org

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

9 months, 2 weeks

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.

10 months, 1 week

3
3
4 0

Questions regarding ARM CCA MEC feature

by Jaehyeon Lee

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

10 months, 2 weeks

1
0
0 0

TF-A Tech Forum on June 12th 2025 - TF-RMM live activation

by Olivier Deprez

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

10 months, 3 weeks

2
1
0 0

Re: MPAMIDR_EL1

by Sona Rebecca Mathew

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.

10 months, 3 weeks

1
0
0 0

MPAMIDR_EL1

by Manoj Ekbote

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

10 months, 3 weeks

1
0
0 0

How to report vulnerabilities

by 王海旺

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

11 months

2
1
0 0

Trusted Firmware v2.13 release announcement

by Olivier Deprez

Hi All, We are pleased to announce the formal release of Trusted Firmware-A version 2.13 bundle of project deliverables. This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, TF-RMM, Trusted Services, and TF-A OpenCI scripts/jobs components. These went live on May, 22nd 2025. Please find references to tags and change logs at the end of this email. Many thanks to the trustedfirmware.org community for the active engagement in delivering this release! Notable features of the release version 2.13 are as follows: TF-A/EL3 * Alto CPU support * Architecture feature support for PMUv3p9. PAUTH_LR and SPE_FDS. * Refactor PSCI to let each CPU core initialise its own context, allowing TF-A to natively handle asymmetric configurations * PSCI Powerdown abandon feature support * SMCCC_FEATURE_AVAILABILITY support based on SMCCC v1.5 specification * Firmware Handoff * Library enhancements to add more TE types in library * All BL interfaces for FVP are now migrated to use Transfer List along in different boot scenarios (RESET_TO_BL1/BL2/BL31) * TC platform is now using Transfer List for booting * HOB creation Library (from edk2) is now hosted in TF-A * New Platforms: mt8189, mt8196, qcs615, RK3576, AM62L Boot flow * Feature Additions * Added discrete TPM support in BL1/BL2 for the RPi3 platform. * Support for MbedTLS PSA Crypto with ROMLIB on FVP. * Redesigned PSA Crypto Key ID management to avoid repeated key creation/destruction. * Test Additions * Support for MbedTLS PSA Crypto with ROMLIB on FVP. * Added basic boot test for TF-RMM with TF-A and TFTF (Realm Payload) in Jenkins CI. * Integrated DRTM ACS test suite into TF-A Jenkins CI. * Added missing test configuration for ROTPK in register on FVP platform. * Build System * Refactored ROTPK key/hash generation to auto-generate required files during build. * mbedTLS Improvements * Migrated to mbedTLS version 3.6.3. Errata/Security mitigations (CPU/GIC) * CVE-2024-5660, CVE-2024-7881 * Cortex-A510, Cortex-A715, Cortex-X4, Cortex-X925, Neoverse V3 Hafnium/SPM (S-EL2) * FF-A v1.2 completed: indirect messaging with service UUIDs. * FF-A v1.3 early adoption: Update to FFA_MEM_PERM_GET ABIs. * StMM integration: provide HOB structure as boot information. * Power management update: * Bootstrapped secondary vCPUs on secondary cores power on flows. * SP's subscription to the power off event. * SP loading: SP artefacts can be bundled in a TL format. I.e SP binary and SP manifest (DTB). * Resuming ECs for interrupt handling assisted by NWd Scheduler when the SP is in waiting state, with sri-interrupts-policy field in the SP manifest. TF-RMM (R-EL2) * Deprivileging RMM code via EL0 App support * Added some support for some RMMv1.1 APIs - "RMI_DEV_MEM_(UN)MAP", support for device granules in "RMI_GRANULE_DELEGATE" and "RMI_GRANULE_UNDELEGATE". * Additional hardening of RMM via compiler flags `-fstack-protector-strong`, '-Wextra', '-Wstrict-overflow', '-D_FORTIFY_SOURCE=2' and '-Wnull-dereference'. * New platform support for RD-V3-R1 and RD-V3-R1-Cfg1 FVPs. * Dynamic discovery of PCIE Root complex topology and device memory from the Boot manifest. Trusted Services (v1.2.0) * Introduced the fTPM SP. The implementation is experimental. * Introduce the new Arm Reference Design-1 AE platform targeting the Automotive segment. It features high-performance Arm Neoverse V3AE Application Processor compute system, Arm Cortex-R82AE based Safety Island, and a Runtime Security Engine (RSE) for enhanced security. * Updated the se-proxy deployment and added support for the Firmware Update Proxy service. The FWU Proxy implements a Platform Security Firmware Update for the A-profile Arm Architecture<https://developer.arm.com/documentation/den0118/latest/> compliant FWU Agent which runs a PSA Certified Firmware Update API 1.0<https://arm-software.github.io/psa-api/fwu/1.0/> compliant client as its backend. TF-A Tests * Enhancements to fuzzing tests (EL3 vendor specific SMC, SDEI, FF-A interface, capability for randomized fuzzing inputs) * Functionality test * Firmware Handoff : AArch32 tests and event log testing * SMCCC_ARCH_FEATURE_AVAILABILITY * RAS system registers, FPMR, SCTLR2, THE and D128 * validate psci_is_last_cpu_to_idle_at_pwrlvl * SPM/FF-A : HOB generation, PPI timer interrupts, v1.2 RXTX headers * RMM: Tests introduced for majority of features developed in RMM * Platform Support * Versal NET * Versal * Neoverse-RD Release tags across repositories: https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/r… https://git.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/tags… https://git.trustedfirmware.org/plugins/gitiles/ci/tf-a-ci-scripts/+/refs/t… https://git.trustedfirmware.org/plugins/gitiles/ci/tf-a-job-configs/+/refs/… https://git.trustedfirmware.org/plugins/gitiles/hafnium/hafnium.git/+/refs/… https://git.trustedfirmware.org/plugins/gitiles/ci/hafnium-ci-scripts/+/ref… https://git.trustedfirmware.org/plugins/gitiles/ci/hafnium-job-configs/+/re… https://git.trustedfirmware.org/plugins/gitiles/TF-RMM/tf-rmm/+/refs/tags/t… https://git.trustedfirmware.org/plugins/gitiles/TS/trusted-services/+/refs/… Change logs: https://trustedfirmware-a.readthedocs.io/en/v2.13.0/change-log.html#id1 https://trustedfirmware-a-tests.readthedocs.io/en/v2.13.0/change-log.html#v… https://hafnium.readthedocs.io/en/v2.13.0/change-log.html#v2-13 https://tf-rmm.readthedocs.io/en/latest/about/change-log.html#v0-7-0 https://trusted-services.readthedocs.io/en/stable/project/change-log.html#v… Regards, Olivier.

11 months, 2 weeks

1
0
0 0

DA developer branches

by Soby Mathew

Hi Everyone, Developer branches for TF-RMM and the kernel, which demonstrate the device assignment setup flow is available. To reproduce this flow on FVP, there is a Shrinkwrap<https://shrinkwrap.docs.arm.com/en/latest/userguide/configstore/cca-3world.…> overlay. Instructions for using it can be found here : https://git.trustedfirmware.org/plugins/gitiles/TF-RMM/tf-rmm.git/+/refs/he… The specific branches for the respective components are: TF-RMM: https://git.trustedfirmware.org/plugins/gitiles/TF-RMM/tf-rmm.git/+/refs/he… Linux: https://gitlab.arm.com/linux-arm/linux-cca/-/tree/cca-1.1/da/proto/rmm-1.1-… kvmtool: https://gitlab.arm.com/linux-arm/kvmtool-cca/-/tree/cca-1.1/da/proto/rmm-1.… TF-A: Changes are merged in master , so tip of master should be good (https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/r…) This release is based on the RMM v1.1 Alpha 12 specification. It includes setting up a secure SPDM session for communication with DSM, TDISP, and IDE, including the RMM-EL3 interface for RP programming. This is entirely new development and has undergone limited internal review. As such, we are aware that the code lacks comprehensive checks and hardening. Additionally, Stage 2 MMU changes for device mappings the Stage 2 SMMU driver are not tested/supported. As a result, Realms cannot access device memory or support device DMA to Realm memory. Furthermore, the TDISP_En flag setting in DVSEC and other DVSEC programming have some gaps. This functionality is still under active development, and the programming and testing is limited to capabilities of the FVP. As development progresses, we will continue to update the branches accordingly. Any changes in user instructions will be reflected in the accompanying documentation. Best Regards Soby Mathew

12 months

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu 1 Jun 2023 11am - 12pm (EDT) (tf-rmm@lists.trustedfirmware.org)

by Karen Power

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

1 year

1
0
1 0

2026

2025

2024

2023

2022

tf-rmm