Hi All,
The next release of the Firmware-A bundle of projects tagged v2.12 has an expected code freeze date of Nov, 8th 2024.
Refer to the release cadence section from TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…).
Closing out the release takes around 6-10 working days after the code freeze.
v2.12 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
--
Thanks,
Govindraj R
Hi Everyone,
The FEAT_MEC enablement patches have now been merged into RMM:
https://github.com/TF-RMM/tf-rmm/commit/8819a19d048b273438690954c151c8333db…
This marks the culmination of several months of work.
The patch series went through two major rewrites as we experimented with different implementation approaches. This also led to a re-design of the delegate scrub flow in RMM, which was merged earlier as a precursor to this work.
We also received design inputs from @Raghu K , which resulted in more fine-grained programming of the MEC registers. In addition, two extra hardening methods were implemented based on this feedback. These can be enabled via the RMM_MEM_SCRUB_METHOD build flag.
In the coming days, we plan to profile the three different scrub methods to determine a more suitable default.
The FEAT_MEC design in RMM and rationale for the hardening is explained here:
https://github.com/TF-RMM/tf-rmm/wiki/RFC:-FEAT_MEC-Design-in-RMM
As usual, please let us know if you find any issues.
Best Regards
Soby Mathew
Hi Everyone,
The Planes patch stack has been merged!
https://github.com/TF-RMM/tf-rmm/commit/d2f72c4ec9e091b8bb12b53fe2bc022351f… .
This update includes more than 15K lines of code changes. Some patches went through 100+ revisions over the last 1.5 year, and we've added significant new framework support as well as test cases to TFTF. As with any large integration, we expect to encounter some issues in the coming days, which we'll be addressing . We already have a list of improvements and fixups identified, and more TFTF tests will follow.
In the meantime, please let us know if you come across any issues or have suggestions for improvements.
Best Regards
Soby Mathew
Hi Everyone,
I'm pleased to announce that Raghupathy K has joined the group of maintainers for TF-RMM. This decision reflects Raghu's significant contributions to the project, including code reviews, design discussions and feature contributions over the past couple of years.
The maintainers file has been updated accordingly : https://github.com/TF-RMM/tf-rmm/blob/main/docs/about/maintainers.rst
Best regards,
Soby Mathew (on behalf of all TF-RMM maintainers)
Hi Everyone,
We merged the new ID sysreg management scheme into RMM today.
Background:
Previously, RMM directly read the ID_xxx sysregs to determine hardware capabilities before enabling features in the Realm world. This approach implicitly required EL3 to enable the feature first, creating a revision lockstep between RMM and the EL3 firmware.
New Scheme:
With the updated ID register management, EL3 capabilities are queried via the SMCCC_ARCH_FEATURE_AVAILABILITY call. RMM now maintains a shadow copy of the ID sysregs in memory (referred to in the codebase as the cached_ID reg). This cached copy is populated during cold boot, and RMM will only access the cached ID regs at runtime.
The design also anticipates future support for FEAT_IDTE3 in TF-A.
Benefits:
* Sanitized Realm view of ID regs: Instead of using a "disallow" mask, RMM now uses an "allow" mask to define what features are exposed.,
* Forward compatibility: Older RMM versions running on newer architectures will not expose previously RES0 fields to realms, thanks to the "allow" mask approach.,
* Feature discrepancy handling: In the future, RMM could detect CPU feature differences and react accordingly.,
* Live migration readiness: This scheme may also help when handling feature differences in live migration scenarios.,
The merge commit can be found here : https://github.com/TF-RMM/tf-rmm/commit/4a9d781892074e8997e73411cfe5a220223…
The current CI tests are passing. There is a chance that we may not have exposed all the bitfields needed, but if you find any failure due to missing ID features, please let us know.
Please be aware that outstanding patches may need to be rebased on top of this.
Best Regards
Soby Mathew
Hi,
Relaying an important announcement about the new Rusted Firmware-A project hosted on trustedfirmware.org:
Today, the Trusted Firmware organization proudly unveils Rusted Firmware-A (RF-A) v0.1 \u2014 a ground breaking open-source prototype that reimagines Trusted Firmware-A (TF-A) through the adoption of the Rust programming language.
Developed in close collaboration between Arm and Google, both Diamond members of the Trusted Firmware community, RF-A has been architected from the ground up for the latest Arm® A-class processors. With a security-first approach, RF-A delivers strong memory safety, enhanced reliability, and modern modularity.
Unlike incremental updates, Rusted Firmware-A is a complete redesign \u2014 free from legacy constraints, built to leverage modern hardware, and designed to provide a robust, maintainable, and future-ready firmware foundation. This milestone reflects years of industry learnings, community insights, and deep collaboration between leading software and silicon providers.
Press release - https://www.trustedfirmware.org/news/rf-a-press-release
Technical blog - https://www.trustedfirmware.org/blog/rf-a-blog
Linkedin post - https://www.linkedin.com/posts/trustedfirmware-org_rusted-firmware-a-rf-a-a…
Regards,
Olivier on behalf of Arm RF-A team.
Hi,
Ok. It seems to be some effect of memory management of kernel and I don't know details about that. Otherwise, your FVP/QEMU setup seems fine.
Best Regards
Soby Mathew
From: neptune <awsomered(a)foxmail.com>
Sent: Wednesday, August 6, 2025 10:49 AM
To: Soby Mathew <Soby.Mathew(a)arm.com>
Subject: Re:[tf-rmm] Re: question about rmm
test both on qemu and fvp.When use fvp, I follow the step of cca-3world in shrinkwrap but with da support.But i don't think da will cause this.And when use qemu, I follow the step in
Building+an+RME+stack+for+QEMU<https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+an…> without da support.
And then, what's strange is that when i use allocated memory,it will cause gpf.Like this.
static void *allocate_granule(void) {
void *page = (void *)__get_free_pages(GFP_KERNEL, 0); // Allocate one page
if (!page) {
printk(KERN_ERR "Failed to allocate granule\n");
}
return page;
}
int create_realm(void)
{
struct smc_result result;
int ret = 10;
void* tmp = allocate_granule();
if (!tmp) {
pr_err("Failed to allocate tmp buffer\n");
return -ENOMEM;
}
memset(tmp, 0, PAGE_SIZE);
memcpy(tmp, (void *)realm_start, PAGE_SIZE);
host_rmi_granule_delegate(virt_to_phys(tmp), &result);
CHECK_RMI_RESULT();
pr_info("host_rmi_granule_delegate %p\n", (uintptr_t)virt_to_phys(tmp));
char dst[9] = {0};
memcpy(dst, tmp, 8);
pr_info("memcpy done %x\n", *(uint64_t *)dst);
host_rmi_granule_undelegate(virt_to_phys(tmp), &result);
CHECK_RMI_RESULT();
pr_info("host_rmi_granule_undelegate done\n");
return 0;
}
------------------ Original ------------------
From: "Soby Mathew" <tf-rmm(a)lists.trustedfirmware.org<mailto:tf-rmm@lists.trustedfirmware.org>>;
Date: Wed, Aug 6, 2025 04:38 PM
To: "neptune"<awsomered(a)foxmail.com<mailto:awsomered@foxmail.com>>;"tf-rmm"<tf-rmm(a)lists.trustedfirmware.org<mailto:tf-rmm@lists.trustedfirmware.org>>;
Cc: "nd"<nd(a)arm.com<mailto:nd@arm.com>>;
Subject: [tf-rmm] Re: question about rmm
Hi Neptune
You are right, I would have expected a Granule protection fault (GPF) when accessing a physical address delegated to realm world. It is difficult to say why, without further information about the platform , EL3 firmware used etc. If the platform is FVP, then the FVP cmd line options would need to be verified.
Would recommend reproducing your test in a shrinkwrap setup https://shrinkwrap.docs.arm.com/en/latest/userguide/configstore/cca-3world.… and see the behavior.
Best Regards
Soby Mathew
From: neptune via tf-rmm <tf-rmm(a)lists.trustedfirmware.org<mailto:tf-rmm@lists.trustedfirmware.org>>
Sent: Tuesday, August 5, 2025 2:02 PM
To: tf-rmm <tf-rmm(a)lists.trustedfirmware.org<mailto:tf-rmm@lists.trustedfirmware.org>>
Subject: [tf-rmm] question about rmm
I'm doing some tests on tf-rmm while found something interesting.
Why this code can execute without error?This code is part of a driver.
__attribute__((aligned(4096)))
static int realm_start(void)
{
return 11;
}
int create_realm(void)
{
struct smc_result result;
int ret = 10;
flush_cache_all();
flush_tlb_all();
isb();
host_rmi_granule_delegate(virt_to_phys(realm_start), &result);
CHECK_RMI_RESULT();
pr_info("host_rmi_granule_delegate %lx\n", (uintptr_t)virt_to_phys(realm_start));
flush_cache_all();
flush_tlb_all();
isb();
ret = realm_start();
pr_info("run realm start %d\n", ret);
char dst[9] = {0};
memcpy(dst, realm_start, 8);
pr_info("memcpy done %x\n", *(uint64_t *)dst);
host_rmi_granule_undelegate(virt_to_phys(realm_start), &result);
CHECK_RMI_RESULT();
pr_info("host_rmi_granule_undelegate done\n");
return 0;
}
Here is the output of linux and tf-rmm
[ 743.248076] realm: loading out-of-tree module taints kernel.
[ 743.260986] realm_create: Module loaded
[ 743.261778] SMC_GRANULE_DELEGATE: addr = 0xeda70000 eda70000
[ 743.265428] host_rmi_granule_delegate eda70000
[ 743.266110] run realm start 11
[ 743.266581] memcpy done 52800160
[ 743.268005] host_rmi_granule_undelegate done
SMC_RMI_GRANULE_DELEGATE eda70000 > RMI_SUCCESS
SMC_RMI_GRANULE_UNDELEGATE eda70000 > RMI_SUCCESS
Hi Everyone,
We are planning a major change to granule scub flow in TF-RMM. This is done mainly in preparation for supporting FEAT_MEC. When FEAT_MEC is present, granules must be zeroed with the appropriate MECID programmed. Previously, RMM performed scrubbing (zeroing) during the transition to the DELEGATED state. However, for FEAT_MEC, granules must be initialized with the correct MECID when they transition into a Realm. The new granule transition flow improves efficiency and eliminates redundant operations while preserving security guarantees.
Key changes:
* Scrubbing now occurs during transitions from DELEGATED to another state, instead of to DELEGATED.,
* This ensures that data is sanitized before a granule is either: Assigned to a new Realm, or reclaimed by the NS Host.,
All RMI_*_CREATE() APIs, which transition granules from DELEGATED to Realm states, and RMI_UNDELEGATE() have been updated to correctly initialize or zero the buffer as needed.
Performance improvements:
* Redundant zeroing previously done during RMI_DATA_CREATE() and RMI_RTT_CREATE() is eliminated.,
* When FEAT_MEC is enabled, scrubbing before initialization (for new Realm usage) is removed, further improving efficiency.,
The patch is here : https://review.trustedfirmware.org/c/TF-RMM/tf-rmm/+/39096/22 . Please let us know if you see some issues with the change.
The FEAT_MEC patch series is available for review here : https://review.trustedfirmware.org/c/TF-RMM/tf-rmm/+/35509/9
Best Regards
Soby Mathew
Hello Jaehyeon,
We are still working on providing support for FEAT_MEC on RMM. More patches are coming in the next few weeks.
In order to run the current patches with MEC enabled, you have to set some more parameters for the FVP:
-C bp.mpe.enable=1 \
-C bp.mpe.block_size_in_bytes=4096 \
-C bp.mpe.corruption_strategy=0 \
-C bp.mpe.ignore_mecid=0 \
-C bp.mpe.output_attributes_parameter_of_core=ExtendedID[62:55]=MPAM_PMG \
-C bp.mpe.output_attributes_parameter_of_core=ExtendedID[38]=MPAM_SP[0] \
-C bp.mpe.output_attributes_parameter_of_core=ExtendedID[37]=MPAM_SP[1] \
-C bp.mpe.output_attributes_parameter_of_core=UserFlags[31:16]=MECID \
-C bp.mpe.non_secure_pas_enc_key=34 \
-C bp.mpe.realm_pas_enc_key=136 \
-C bp.mpe.root_pas_enc_key=68 \
-C bp.mpe.secure_pas_enc_key=17 \
-C cluster0.mec_support_level=2 \
-C cluster0.rme_mecid_width=16 \
-C cluster1.mec_support_level=2 \
-C cluster1.rme_mecid_width=16 \
I have attached a Shrinkwrap overlay in case you want to use it instead.
Let me know if you have any questions.
All the best,
Juan Pablo
--
From: Jaehyeon Lee
Sent: 23 Jun 2025 6:07 a.m
To: tf-rmm(a)lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-rmm@lists.trustedfirmwar…>
Subject: [tf-rmm] Questions regarding ARM CCA MEC feature
Hello tf-rmm group,
I'm currently conducting research on the MEC (Memory Encryption Context) feature for sharing memory pages across multiple realms, and I'm interested in testing and potentially extending this functionality w/ new use-cases.
I noticed that there are mec-proto branches available across the TF-A repositories, including rmm, linux, kvmtool, and tf-a, specifically for the CCA memory encryption context. However, I've been unable to successfully launch a system using these branches on the FVP models.
Is there a reference setup or guidance available for bringing up a MEC-enabled Realm environment, similar to the DA branches discussed here<https://lists.trustedfirmware.org/archives/list/tf-rmm@lists.trustedfirmwar…>?
Also, extending MEC feature to allow sharing pages across multiple realms are feasible w/ current hardware (RME w/ MPE) spec? w/ utilizing MEC_STATE_SHARED state in RMM 1.1 alp14 spec.
Thank you,
Jaehyeon Lee
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
