- tf-rmm - lists.trustedfirmware.org

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

3 months

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

3 months

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

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

4 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

4 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

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

4 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

4 months, 4 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

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

5 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

tf-rmm