Hi,
In a multi-NUMA architecture, the RMM firmware is loaded to a memory of a numa. When the confidential virtual machine triggers VM_Exit, inst cache miss exists in running of code of the RMM, and an instruction needs to be fetched from the DRAM to the instruction cache. If the vCPU and RMM firmware memory do not belong to the same NUMA node, the instruction fetch delay is longer and the performance is poorer. I would like to ask if there is an optimization plan for this problem?
Hi,
We would like to propose the following topic for discussion at the Tech Forum tomorrow.
* RME Granule Protection Table (GPT) block fusing
The GPT L1 entries needs to be fused to avoid TLB shattering for RME enabled CPUs. We will talk about the different prototype approaches tried in TF-A (EL3 firmware) and issues with each approach. We have a patch in review in which implements the “brute force” fusing algorithm. We explain our reasoning for picking this approach and possible future enhancements which may resolve some of the issues anticipated.
Also the fine- grained locking scheme implemented for GPT manipulation will also be discussed.
The patch in review is here : https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/26674.
For design details of the GPT Library, please refer here : https://trustedfirmware-a.readthedocs.io/en/latest/components/granule-prote… .
Best Regards
Soby Mathew
-----Original Appointment-----
From: Google Calendar <calendar-notification(a)google.com> On Behalf Of Trusted Firmware Public Meetings
Sent: Thursday, February 22, 2024 10:27 PM
To: tf-a(a)lists.trustedfirmware.org; marek.bykowski(a)gmail.com; okash.khawaja(a)gmail.com
Subject: [TF-A] Updated invitation with note: TF-A Tech Forum @ Every 2 weeks from 9am to 10am on Thursday (MST) (tf-a(a)lists.trustedfirmware.org)
When: Occurs every 2 week(s) on Thursday effective 07/03/2024 from 16:00 to 17:00 Europe/London.
Where:
TF-A Tech Forum
We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this
This event has been updated with a note:
"Updating invite link"
Changed: description
Description
CHANGED
We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.
Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website.
Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…>
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvd…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmy%2Ftruste…>
One tap mobile
+16465588656,,9159704974# US (New York)
+16699009128,,9159704974# US (San Jose)
Dial by your location
+1 646 558 8656 US (New York)
+1 669 900 9128 US (San Jose)
877 853 5247 US Toll-free
888 788 0099 US Toll-free
Meeting ID: 915 970 4974
Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…>
When
Every 2 weeks from 9am to 10am on Thursday (Mountain Standard Time - Phoenix)
Guests
tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
marek.bykowski(a)gmail.com<mailto:marek.bykowski@gmail.com>
okash.khawaja(a)gmail.com<mailto:okash.khawaja@gmail.com>
View all guest info<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…>
RSVP for tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> for all events in this series
Yes<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…>
No<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…>
Maybe<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…>
More options<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…>
Invitation from Google Calendar<https://calendar.google.com/calendar/>
You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>
Hi Everyone,
We have been having instances of spam on the tf-rmm mailing list. We have made some changes on the default posting rules now and will monitor the outcome in the coming days.
Best Regards
Soby Mathew
Hi Everyone,
The EAC5 development branch has been merged back to the `main` and tagged (https://github.com/TF-RMM/tf-rmm/releases/tag/rmm-spec-v1.0-eac5) . TF-RMM is now RMM v1.0 EAC5 [1] compliant and all the corresponding Normal world software entities need to be updated to this version of ABI to work with RMM. The Normal world entities would be published later in due course, and we will update the list with relevant information as it becomes available.
The tf-a-tests changes have been merged to master and can be found here : https://git.trustedfirmware.org/TF-A/tf-a-tests.git/commit/?id=3dc2d746aa4b… . For TF-A, the master branch is compatible with EAC5 changes.
If you find any issues, please report them via mailing list, tf-rmm discord channel or github issues.
Best Regards
Soby Mathew
[1] https://developer.arm.com/documentation/den0137/1-0eac5/?lang=en
Hi Everyone,
The initial integration of CBMC (C Bounded Model checking) for TF-RMM has been merged. Please refer to the application note here for more details on how to trigger CBMC analysis/coverage/assert targets on TF-RMM implementation : https://tf-rmm.readthedocs.io/en/latest/resources/application-notes/cbmc.ht…
Best Regards
Soby Mathew
Hi,
I wonder if there is or there is a plan to develop a dedicated tool that allows a realm developer to calculate Realm Initial Measurements (RIMs) for realms(?)
As you know, the remote attestation mechanism requires a verifier to be provisioned with reference values. In this case, a realm verifier should have access to the initial reference measurement (RIM) of a realm that is intended to be run on a remote Arm CCA platform.
The algorithm that measures the initial state of realms (RIM) is higly sensitive to the content of a realm memory and the order of RMI operations. This means that not only the content of populated realm memory matters but also the implementation of the host components (e.g. kvm, kvmtool/qemu). For example, in the reference implementation of https://gitlab.arm.com/linux-arm/kvmtool-cca, the layout of memory and the content of DTB highly depend on the provided options (DTB is generated in run-time). Unfortunatelly, the content of DTB also depends on the linking order of object files (the order of DTB generation is imposed by __attribute__((constructor)) that is used to register devices). This complicates development of a separate tool for caclulating RIM, as the tool would have to emulate all quirks of the kvmtool.
One of the solution of retrieving Realm Initial Measurements seems to be running the whole firmware/software (e.g. kvmtool/Linux host/TF-RMM) stack on the FVP emulator and gathering the RIM directly from the TF-RMM. This would require a realm developer to have access to the whole firmware/software stack and the emulator of the CCA platform. This might not always be an option.
The other solution would require the implementation of a dedicated tool. For instance, a sensible approach could be to extend the functionality of kvmtool, which can be run on an ordinary Linux machine.
Is Arm going to develop a dedicated tool(-s) for calculating RIMs?
What is the recommended way of retrieving/calculating RIMs for realms?
Kind regards,
Piotr
Hello all,
We have added a GitHub workflow to RMM which allows the former to build
and run the unittests along with their corresponding coverage report
and upload such report in .html format to GitHub.
The workflow is automatically triggered when new pushes are done to the
main branch.
In order to access to the coverage report, you can either
* click on the green check symbol next to the latest commit, from
there to "details" on the "Coverage on unittests for RMM" action on
the pop up window and once in the action page, click on "Summary" on
the left side menu. The report will appear in the "Artifacts"
section as a .zip file with the name "coverage-results" or
* On the TF-RMM repo main page, click on "Actions" and then click on
the "Coverage on unittests for RMM" action corresponding to the
latest commit. You can then access to the report as explained on the
previous bullet.
Please keep in mind that reports older than 90 days will be
automatically deleted.
Thanks,
Javier
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.
