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