Hi All,
We are pleased to announce the formal release of Trusted Firmware-A version 2.10 bundle of project deliverables.
This includes Trusted Firmware-A, Trusted Firmware-A Tests, Hafnium, RMM and TF-A OpenCI Scripts/Jobs 2.10 releases involving the tagging of multiple repositories.
These went live on 22nd November 2023.
Please find references to tags and change logs at the end of this email.
Many thanks to the community for the active engagement in delivering this release!
Notable Features of the Version 2.10 Release are as follows:
TF-A/EL3 Root World
* New Features:
* Firmware handoff library support
* Improvements to BL31 runtime exception handling
* Context management refactoring for RME/4 worlds
* Gelas, Nevis & Travis CPUs support
* V8.9 features enabled (FEAT_ HAFT, RPRFM, LRCPC3, MTE_PERM)
TF-A Boot BL1/BL2
* New Features
* Trusted Boot support for ECDSA (Elliptic Curve Digital Signature Algorithm)
* Migrated to PSA crypto API’s
* Improved the GUID Partition Table (GPT) parser.
* Various security Improvements and threat Model updates for ARM CCA
* Signer id extraction Implementation
Hafnium/SEL2 SPM
* New Features:
* FF-A v1.2: FFA_YIELD with time-out; EL3 SPMDs LSPs communication; memory sharing updates.
* Memory region relative base address field support in SP manifests.
* Interrupt re-configuration hypervisor calls.
* Memory management: S2 PT NS/S IPA split
* SMCCCv1.2+ compliance fixes.
* Feature parity test improvements, EL3 SPMC and Hafnium (S-EL2 SPMC)
TF-RMM/REL2
* New Feature/Support
* Fenimore v1.0 EAC5 aligned implementation.
* TFTF Enhancements for RME testing
* Initial CBMC support
* NS SME support in RMM
* BTI support for RMM
Errata
* Errata implemented (1xCortex-X2/ Matterhorn-ELP, 1xCortex-A710/Matterhorn, 1xNeoverse N2/Perseus, 2xNeoverse V2/Demeter, Makalu ELP/Cortex X3, Klein/Cortex-A510)
* Fix some minor defects with version in a few errata that applies for some follow up revisions of the CPUs. (Neoverse V1, Cortex-X2, Cortex-A710)
TF-A Tests
* Core
* Added errata management firmware interface tests.
* Added firmware handoff tests.
* Introduced RAS KFH support test.
* SPM/FF-A
* Support SMCCCv1.2 extended GP registers set.
* Test SMCCC compliance at the non-secure physical instance.
* Test secure eSPI interrupt handling.
* Test FF-A v1.2 FFA_PARTITION_INFO_GET_REGS interface.
* RMM
* Added FPU/SVE/SME tests
* Added multiple REC single CPU tests.
* Added PAuth support in Realms tests.
* Added PMU tests.
Platform Support
* New platforms added:
* Aspeed AST2700, NXP IMX93, Intel Agilex5, Nuvoton NPCM845x, QTI MDM9607, MSM8909, MSM8939, ST STM32MP2
Release tags across repositories:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.10https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.10https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/hafnium-ci-scripts.git/tag/?h=v2.10https://git.trustedfirmware.org/ci/hafnium-job-configs.git/tag/?h=v2.10https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.4.0
Change logs:
https://trustedfirmware-a.readthedocs.io/en/v2.10/change-log.html#id1https://trustedfirmware-a-tests.readthedocs.io/en/v2.10/change-log.html#ver…https://hafnium.readthedocs.io/en/latest/change-log.html#v2-10https://tf-rmm.readthedocs.io/en/tf-rmm-v0.4.0/about/change-log.html#v0-4-0
Regards,
Olivier.
Hi All,
The next release of the Firmware-A bundle of projects tagged v2.10 has an expected code freeze date of Nov, 7th 2023.
Refer to the Release Cadence section from TF-A documentation (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about…).
Closing out the release takes around 6-10 working days after the code freeze.
Preparations tasks for v2.10 release should start in coming month.
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 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 & Regards,
Olivier.
Hi,
I would like to restart a discussion that we already had a few years
ago on a thread called "SMC to intentionally trigger a panic in TF-A"
(https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…)
but that petered out without any real resolution (and resulted in me
ultimately not implementing the feature I was hoping to add).
Basically, we are repeatedly stumbling over the problem that we have a
use case for some platform-independent SMC API that we want to
implement in TF-A, but don't have an appropriate SMC FID range to put
it. My request from a few years ago was about implementing a call to
intentionally trigger a panic in TF-A for test-automation purposes.
Today we came up with a use case where a Trusted OS wants to query
BL31 about the location of a shared log buffer:
https://review.trustedfirmware.org/20478 .
Currently, the available SMC ranges are Arm, CPU, SiP, OEM, Standard,
Hypervisor, TA and TOS. The SiP, OEM and TOS ranges are all specific
to a single silicon vendor, OEM or trusted OS implementation, so they
are not good targets to implement APIs that would make sense to be
shared among multiple of these. In theory, the Standard range would
probably be the right target to implement calls that are independently
useful for multiple platforms / OSes... but as far as I understand,
adding a new call to that range requires petitioning Arm to update the
SMC calling convention itself, which is a ridiculously high bar to
implement a small utility API. In practice, the only choice we have
for implementing these kinds of calls is to let every OEM, SiP or TOS
assign its own (different) FID for it and then write separate SMC
handlers for each in TF-A that all end up calling the same underlying
function... which creates a lot of unnecessary code duplication and
identifier soup (especially in the case of SMCs for the non-secure OS
which would then be implemented by a platform-independent Linux driver
that needs a big mapping table to decide which FID to use on which
platform for the same API).
I think it would be very useful if there was another range of easily
allocatable FIDs that developers could just add to with a simple TF-A
CL without having to go through a huge specification update process.
There are still 41 OENs unused in the Arm SMCCC, and I don't think any
new ones were added in the 10 years that the specification existed...
so we are really not going to run out of them any time soon. If we
could get even one of those OENs for this purpose, we would have 64K
FIDs to use up for our small, simple platform-independent API needs,
which should last us a long while. We could maybe call it the "Secure
Monitor range" and say the FIDs are specific to a certain
implementation of Secure Monitor (e.g. TF-A). Then there could just be
a header file in the TF-A sources that serves as the authoritative FID
assignment table for TF-A, and anyone with a sufficiently useful idea
(subject to TF-A maintainer review) for a platform-independent API
like this could add it there by just uploading a patch.
I recently argued for a similar "simple tag allocation" concept on
https://github.com/FirmwareHandoff/firmware_handoff and it found
support there, so I hope I'll be able to convince you that it would be
useful for SMC FIDs as well?
Hi Olivier Deprez,
We use the SPM_MM framework mainly for read/write control of security variables. We do not want to modify the original application code at this time.
At the same time we want to add support for the new SPMD framework based code.
________________________________
Hi Baopeng,
By "code based on the SPM_MM framework" I assume you refer to a secure service running in a S-EL0 partition based on the MM protocol? If you can share this information, what kind of service is this implementing? RAS handling, secure variables, TPM back end, other? What kind of interface is needed to access the service? asynchronous with interrupts? synchronous with SMC from normal world? Another question is why do you need to collocate the SPMD if the MM implementation is already achieving the scenarios you need?
Ideally you'd want to migrate this service to run on top of:
* the EL3 FF-A SPMC https://trustedfirmware-a.readthedocs.io/en/latest/components/el3-spmc.html * or if the HW/chipset implements it, the S-EL2 FF-A SPMC https://hafnium.readthedocs.io/en/latest/secure-partition-manager/index.htm…
Knowing the kind of S-EL0 service would help narrowing the effort for a migration.
FF-A (https://developer.arm.com/documentation/den0077/latest/) is a modern evolution of MM (https://developer.arm.com/documentation/den0060/latest) and any functionality achieved by the MM protocol can be handled by FF-A. For example the MM_COMMUNICATE interface can be easily swapped by the FFA_MSG_SEND_DIRECT_REQ interface.
Regards, Olivier.
________________________________ From: baopeng (A) via TF-A tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Sent: 21 February 2024 07:10 To: tf-a(a)lists.trustedfirmware.org tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] Re: Request for help
Hi Olivier Deprez,
We have developed code based on the SPM_MM framework and do not want to reconstruct the code. However, we want to adapt the code to the SPMD framework.
What should we do?
________________________________
Hi Baopeng,
SPM_MM is the legacy implementation for a secure partition manager relying on the MM protocol. This implementation gets deprecated in favor of FF-A based implementations (what you refer to as SPMD + SPMC). Both implementations aren't compatible and it is discouraged to attempt co-locating both. It may be more palatable and future proof to transition all your SW stack to be compliant to FF-A standard.
We may help you better if you tell a bit more about the reason for mixing both implementations in the same build.
Regards, Olivier.
________________________________ From: baopeng (A) baopeng1@huawei.commailto:baopeng1@huawei.com Sent: 20 February 2024 02:19 To: tf-a-owner(a)lists.trustedfirmware.org tf-a-owner@lists.trustedfirmware.orgmailto:tf-a-owner@lists.trustedfirmware.org Subject: Request for help
Dear Sir/ Madam,
we need to support the simultaneous loading of SPMD and SPM_MM due to project reasons.
However, we notice that the makefile of SPM_MM of ATF does not support the simultaneous loading of SPMD and SPM_MM by default.
I would like to ask what is the main reason for making the current restrictions?
This event has been updated with a note:
"Updating invite link"
Changed: description
TF-A Tech Forum
Every 2 weeks from 9am to 10am on Thursday
Mountain Standard Time - Phoenix
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/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
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-freeMeeting ID: 915 970
4974Find your local number: https://zoom.us/u/ad27hc6t7h
Guests
tf-a(a)lists.trustedfirmware.org
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
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 ,
We want to include ENABLE_LTO option in platform build.
Can you please recommend if this can be passed only on the build command line, or it can be included in the platform makefile (platform.mk) also.
Regards,
Prasad.
Hello,
In the file lib/xlat_tables/xlat_tables_common.c and other associated files, there are instances where if...else if constructs lack an else statement, resulting in violations during the Coverity MISRA-C analysis for the ZynqMP platform.
Addressing this issue added empty else statement to resolve the issue but it is related to core translational table logic function. Is it possible to address this issue? Please provide your suggestions.
Regards,
Nithin G
Hi folks,
If you don’t use any of the JavaScript-based tooling from the TF-A repository then you can safely ignore this.
I’ve just updated TF-A’s Node.js dependencies, including the minimum version of Node.js required to use the JavaScript-based hooks and tooling from the repository (previously v16, now v20). If you use these and you find that they have started throwing errors, make sure that you are rebased on the latest version of the integration branch, and then run:
npm ci
If you need to commit changes while the tools are erroring, you can commit with the `-n` flag to skip the commit hooks:
git commit -n <usual commit flags…>
Please let me know if you run into any issues.
Cheers,
Chris
Hi Olivier Deprez,
One more question, the SPM_MM code will not be removed from the main repository, right?
________________________________
Hi Olivier Deprez,
We use the SPM_MM framework mainly for read/write control of security variables. We do not want to modify the original application code at this time.
At the same time we want to add support for the new SPMD framework based code.
________________________________
Hi Baopeng,
By "code based on the SPM_MM framework" I assume you refer to a secure service running in a S-EL0 partition based on the MM protocol? If you can share this information, what kind of service is this implementing? RAS handling, secure variables, TPM back end, other? What kind of interface is needed to access the service? asynchronous with interrupts? synchronous with SMC from normal world? Another question is why do you need to collocate the SPMD if the MM implementation is already achieving the scenarios you need?
Ideally you'd want to migrate this service to run on top of:
* the EL3 FF-A SPMC https://trustedfirmware-a.readthedocs.io/en/latest/components/el3-spmc.html * or if the HW/chipset implements it, the S-EL2 FF-A SPMC https://hafnium.readthedocs.io/en/latest/secure-partition-manager/index.html...<https://hafnium.readthedocs.io/en/latest/secure-partition-manager/index.htm…>
Knowing the kind of S-EL0 service would help narrowing the effort for a migration.
FF-A (https://developer.arm.com/documentation/den0077/latest/) is a modern evolution of MM (https://developer.arm.com/documentation/den0060/latest) and any functionality achieved by the MM protocol can be handled by FF-A. For example the MM_COMMUNICATE interface can be easily swapped by the FFA_MSG_SEND_DIRECT_REQ interface.
Regards, Olivier.
________________________________ From: baopeng (A) via TF-A tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Sent: 21 February 2024 07:10 To: tf-a(a)lists.trustedfirmware.org tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Request for help
Hi Olivier Deprez,
We have developed code based on the SPM_MM framework and do not want to reconstruct the code. However, we want to adapt the code to the SPMD framework.
What should we do?
________________________________
Hi Baopeng,
SPM_MM is the legacy implementation for a secure partition manager relying on the MM protocol. This implementation gets deprecated in favor of FF-A based implementations (what you refer to as SPMD + SPMC). Both implementations aren't compatible and it is discouraged to attempt co-locating both. It may be more palatable and future proof to transition all your SW stack to be compliant to FF-A standard.
We may help you better if you tell a bit more about the reason for mixing both implementations in the same build.
Regards, Olivier.
________________________________ From: baopeng (A) baopeng1@huawei.commailto:baopeng1@huawei.com Sent: 20 February 2024 02:19 To: tf-a-owner(a)lists.trustedfirmware.org tf-a-owner@lists.trustedfirmware.orgmailto:tf-a-owner@lists.trustedfirmware.org Subject: Request for help
Dear Sir/ Madam,
we need to support the simultaneous loading of SPMD and SPM_MM due to project reasons.
However, we notice that the makefile of SPM_MM of ATF does not support the simultaneous loading of SPMD and SPM_MM by default.
I would like to ask what is the main reason for making the current restrictions?
