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
