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
