Hi All,
In preparation to the Firmware-A v2.12 bundle release the following TF-A/TF-A-tests/Hafnium/RMM/CI project tags were applied:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a/+/refs/tags/v2.12-r…https://git.trustedfirmware.org/tf-a-tests/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/tf-a-ci-scripts/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/tf-a-job-configs/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/hafnium/hafnium.git/+/refs/tags/v2.12-rc0https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/+/refs/tags/v2.12…https://git.trustedfirmware.org/ci/hafnium-job-configs.git/+/refs/tags/v2.1…https://git.trustedfirmware.org/TF-RMM/tf-rmm/+/refs/tags/tf-rmm-v0.6.0-rc0
Trees are frozen still accepting security or bug fixes until the release close down happening end next week (hopefully!).
For partners, it will help if tests are run against those trees on downstream platforms and spot any issue hit before the final tagging.
--
Thanks,
Govindraj R
________________________________
From: Govindraj Raja via TF-A-Tests <tf-a-tests(a)lists.trustedfirmware.org>
Sent: Monday, October 14, 2024 20:18
To: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org>; tf-a-tests(a)lists.trustedfirmware.org <tf-a-tests(a)lists.trustedfirmware.org>
Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>; tf-rmm(a)lists.trustedfirmware.org <tf-rmm(a)lists.trustedfirmware.org>; trusted-services(a)lists.trustedfirmware.org <trusted-services(a)lists.trustedfirmware.org>
Subject: [Tf-a-tests] Firmware-A v2.12 release code freeze notification
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
--
TF-A-Tests mailing list -- tf-a-tests(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-a-tests-leave(a)lists.trustedfirmware.org
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,
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
