We are pleased to announce the release of Trusted Firmware-A version 2.8 bundle of project deliverables.
This includes Trusted Firmware-A version 2.8, Trusted Firmware-A Tests version 2.8, Hafnium version 2.8 and TF-A OpenCI Scripts/Jobs 2.8 Releases involving the tagging of multiple repositories.
These went live on 21st November 2022. The repositories are now open again to take patches under review.
On behalf of the TF-A project maintainers, I would like to thank all of the Trustedfirmware.org TF-A Project community for their efforts since the last release.
Notable Features of the Version 2.8 Release across repositories are as follows:
TF-A Project Repository
* Architectural enablement (Arm v8.8 etc)
* Added Branch Record Buffer Extension (FEAT_BRBE)
* Added Pointer Authentication Extension helper support for QARMA3 (FEAT_PACQARMA3)
* Partial support for trapping support for RNDR/RNDRRS (FEAT_RNG_TRAP)
* Added Trace Buffer Extension (FEAT_TRBE)
* Added SVE fall back if SME not available (FEAT_SME)
* Support full SVE vector Length (FEAT_SVE)
* Added support for DRTM (Dynamic Root of Trust Measurement )
* Hunter ELP CPU support added
* Twenty Four (24) Errata Mitigations for Cortex-A710 , A510, X3, X2, A76, A77, A78C, Neoverse N1, N2, GIC-600
* Ethos-N Driver support for SMMU
* Secure Payload Dispatcher added for ProvenCore RTOS
* EL3 SPMC feature hardening
* CCA Bootflow chain of trust support for AEM FVP
* CCA RME development to support TF-RMM upstreaming
Hafnium Project Repository
* FF-A v1.1 EAC0 additions
* Partition runtime model and CPU cycle allocation modes.
* Interrupt handling and managed exit flows.
* Memory sharing.
* Framework notifications and indirect messaging.
* Added FF-A console log ABI.
* Added support for GICv3.1 extended INTID ranges.
* Image footprint optimisation.
* Improved SVE support and test coverage.
* FF-A v1.0 ACS test suite integration in Open CI.
TF-A Tests Project Repository
* TF-A Tests support for 4 new platforms (N1SDP, RD-N2, RD-N2-Cfg1, RD-V1)
* TF-A Tests CCA RME Realm Payload Testing
* TF-A Tests FF-A v1.1 Secure interrupts Testing
Platform Support
* Three (3) new platforms added including Arm TC2
* Thirty (30) platforms updated
* Initial support within TF-A OpenCI CI scripts repository for automating end-to-end boot tests (TF-A -> Linux shell prompt) on QEMU
Patch Statistics Across all Repositories
* Approx 1100 Patches merged since v2.7 June 2022 release
Please refer to the TF-A [1], Hafnium [2] and TF-A Tests [3] changelogs for the complete summary of changes from the previous release.
TF-A [4], TF-A Test [5], Hafnium [6], TF-A OpenCI Scripts [7] and TF-A OpenCI Jobs [8] repositories are available along with the compatible TF-RMM repository [9] and documentation [10].
[1] https://trustedfirmware-a.readthedocs.io/en/v2.8/change-log.html#id1 [2] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… - v2_8<https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d…>
[3] https://trustedfirmware-a-tests.readthedocs.io/en/v2.8/change-log.html#vers…
[4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.8
[5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.8
[6] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.8
[7] https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.8
[8] https://git.trustedfirmware.org/ci/tf-a-job-configs.git/tag/?h=v2.8
[9] https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tag/?h=tf-rmm-v0.2.0
[10] https://tf-rmm.readthedocs.io/en/tf-rmm-v0.2.0/
Hi,
Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
87 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 382009: (OVERRUN)
________________________________________________________________________________________________________
*** CID 382009: (OVERRUN)
/lib/psci/psci_on.c: 80 in psci_cpu_on_start()
74 * CPU_ON platform hooks have been implemented.
75 */
76 assert((psci_plat_pm_ops->pwr_domain_on != NULL) &&
77 (psci_plat_pm_ops->pwr_domain_on_finish != NULL));
78
79 /* Protect against multiple CPUs trying to turn ON the same target CPU */
>>> CID 382009: (OVERRUN)
>>> Overrunning callee's array of size 8 by passing argument "target_idx" (which evaluates to 4294967295) in call to "psci_spin_lock_cpu".
80 psci_spin_lock_cpu(target_idx);
81
82 /*
83 * Generic management: Ensure that the cpu is off to be
84 * turned on.
85 * Perform cache maintanence ahead of reading the target CPU state to
/lib/psci/psci_on.c: 160 in psci_cpu_on_start()
154 psci_set_aff_info_state_by_idx(target_idx, AFF_STATE_OFF);
155 flush_cpu_data_by_index(target_idx,
156 psci_svc_cpu_data.aff_info_state);
157 }
158
159 exit:
>>> CID 382009: (OVERRUN)
>>> Overrunning callee's array of size 8 by passing argument "target_idx" (which evaluates to 4294967295) in call to "psci_spin_unlock_cpu".
160 psci_spin_unlock_cpu(target_idx);
161 return rc;
162 }
163
164 /*******************************************************************************
165 * The following function finish an earlier power on request. They
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
Hello TF-A Community,
The meeting invite this week has been updated with an agenda.
In case you have not seen this the details are:
The TF-RMM component was published last week and was announced in this mailing list:
https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
This week Javier Almansa Sobrino of the TF-RMM team would like to present on the TF-RMM Unit test framework
The TF-RMM Unit test framework allows the exercising and validation of the software components of TF-RMM to be performed natively on the development host, making the development of new features, as well as the debugging of existing ones, easier.
This talk will introduce this framework as well as the fake_host architecture for TF-RMM which allows the building and running of TF-RMM natively on the development host. We will also discuss how to implement unit tests for different components and we will introduce some features such as code coverage test for TF-RMM.
Thanks Joanna
Meeting details are:
Join Zoom Meeting
https://armltd.zoom.us/j/97858987231?pwd=U3NxdEk2YjI0OS90NzE1WEdHWE10Zz09&f…
Meeting ID: 978 5898 7231
Passcode: 472153
One tap mobile
+16465189805,,97858987231#,,,,*472153# US (New York)
+13462487799,,97858987231#,,,,*472153# US (Houston)
Dial by your location
+1 646 518 9805 US (New York)
+1 346 248 7799 US (Houston)
+1 408 638 0968 US (San Jose)
Meeting ID: 978 5898 7231
Passcode: 472153
Find your local number: https://armltd.zoom.us/u/adRXFKP35m
Join by SIP
97858987231(a)zoomcrc.com
Join by H.323
162.255.37.11 (US West)
162.255.36.11 (US East)
115.114.131.7 (India Mumbai)
115.114.115.7 (India Hyderabad)
213.19.144.110 (Amsterdam Netherlands)
213.244.140.110 (Germany)
103.122.166.55 (Australia Sydney)
103.122.167.55 (Australia Melbourne)
209.9.211.110 (Hong Kong SAR)
149.137.40.110 (Singapore)
64.211.144.160 (Brazil)
69.174.57.160 (Canada Toronto)
65.39.152.160 (Canada Vancouver)
207.226.132.110 (Japan Tokyo)
149.137.24.110 (Japan Osaka)
Meeting ID: 978 5898 7231
Passcode: 472153
This event has been updated with a note:
"The TF-A Tech Forum will be running this week."
Changed: description
TF-A Tech Forum
Thursday Nov 17, 2022 ⋅ 4pm – 5pm
United Kingdom Time
The TF-A Tech Forum is being run this week.The TF-RMM component was
published last week and was announced in this mailing list
posting https://lists.trustedfirmware.org/archives/list/tf-a@lists.tru…
week the Javier Almansa Sobrino of the TF-RMM team would like to present on
the TF-RMM Unit test frameworkThe TF-RMM Unit test framework allows
the exercising and validation of the software components of TF-RMM to be
performed natively on the development host, making the development of new
features, as well as the debugging of existing ones, easier. This talk
will introduce this framework as well as the fake_host architecture for
TF-RMM which allows the building and running of TF-RMM natively on the
development host. We will also discuss how to implement unit tests for
different components and we will introduce some features such as code
coverage test for
TF-RMM.=======================================================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/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One 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
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
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,
I am trying to send a patch to review.trustedfirmware.org but I get a
Permission denied error.
===========================
$ git push
jforissier@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a
HEAD:refs/for/integration
jforissier(a)review.trustedfirmware.org: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
$ git clone "ssh://
jforissier@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a"
Cloning into 'trusted-firmware-a'...
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
$ ssh -p 29418 jforissier(a)review.trustedfirmware.org
jforissier(a)review.trustedfirmware.org: Permission denied (publickey).
===========================
I can see my ssh key at https://review.trustedfirmware.org/settings/. I
tried to upload it again, I also added -i to the ssh command to make sure
the right key is used. What am I doing wrong?
Thanks,
--
Jerome
Hi,
The PSCI specification defines two different power state coordination modes
for CPU_SUSPEND that can be used to put a core or a group of cores into a
low-power state. These modes are the platform-coordinated mode (default)
and the OS-initiated mode (optional). OS-initiated mode is currently not
supported by TF-A, while both modes are supported by the Linux Kernel.
Requesting reviews for the patches [1] adding support for OS-initiated mode
in TF-A and the corresponding tests in TF-A-Tests. Any feedback and
comments are much appreciated.
Thanks in advance!
Wing
[1] https://review.trustedfirmware.org/q/topic:psci-osi
Hi,
The PSCI specification defines two different power state coordination modes
for CPU_SUSPEND that can be used to put a core or a group of cores into a
low-power state. These modes are the platform-coordinated mode (default)
and the OS-initiated mode (optional). OS-initiated mode is currently not
supported by TF-A, while both modes are supported by the Linux Kernel.
Requesting reviews for the patches [1] adding support for OS-initiated mode
in TF-A and the corresponding tests in TF-A-Tests. Any feedback and
comments are much appreciated.
Thanks in advance!
Wing
[1] https://review.trustedfirmware.org/q/topic:psci-osi
Hi all,
As documented in the Release Cadence section of the TF-A documentation (https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…) the v2.8 release has an expected code freeze date of 3rd week of November 2022.
That equates to the start of that week Monday 14th November which is one calendar month away from tomorrow when the rc0 tag will be applied. Closing out the release takes around 6-10 working days normally over the last few releases.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
Preparations for v2.8 release is already underway.
Thanks
Joanna
Hi,
When a core is in debug recovery mode its caches are not invalidated
upon reset, so the L1 and L2 cache contents from before reset are
observable after reset. Similarly, debug recovery mode of DynamIQ
cluster ensures that contents of the shared L3 cache are also not
invalidated upon transition to On mode.
A common use case of booting cores in debug recovery mode is to boot
with caches disabled and preserve the caches until a point where
software can dump the caches and retrieve their contents. TF-A however
unconditionally cleans and invalidates caches at multiple points
during boot, e.g. in bl31_entrypoint when cleaning bss and .data
sections. This will not only lose the cache content needed for
debugging but will potentially corrupt memory as well, leading to bugs
when booting in recovery mode.
Can we make CMOs in lib/aarch64/cache_helpers.S conditional upon some
platform hook to address above scenario? Happy to work on a patch if
the idea of conditional CMOs makes sense.
Thanks,
Okash
This event has been canceled with a note:
"No topics received so cancelling this week."
TF-A Tech Forum
Thursday Nov 3, 2022 ⋅ 4pm – 5pm
United Kingdom Time
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/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One 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
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
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 a TF-A Tech forum scheduled for this Thursday at 4pm GMT. Note the UK clocks moved to GMT from BST last weekend so the meeting may appear an hour different than in previous weeks in your calendar.
At this time I do not have any topics to present. Please do reach out to me if you have any topics you would like to present to the TF-A community.
If I do not find a topic or hear from the community that they have a topic I will cancel end of day this coming Wednesday 2nd November.
Thanks
Joanna
Hello,
Just a quick follow-up on this question of using an HSM (or in general, some form of Key Management Infrastructure) to sign TF-A images.
U-Boot has support for this with its mkimage utility (see https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt#L…). This appears to a custom engine in OpenSSL (and in this case, the pkcs11 engine). My questions are:
1. Does TF-A’s cert_create tool support using custom OpenSSL engines?
2. If so, is there a procedure for using this?
3. If not, is there a plan to add support for this in the roadmap somewhere?
* Or, in general, is there a plan to add HSM support for TF-A image signing?
Thanks,
Brian
Hello,
After learning the current implementation of plat_get_stack_protector_canary in TF-A, i am curious about why we not make the first byte of canary an NULL byte for better security?
Hello,
I am about to debug RME feature with ARM DS on
FVP_Base_RevC-2xAEMvA_11.19_14 platform. I am using the Trusted Firmware
with RME extension based on this description
https://trustedfirmware-a.readthedocs.io/en/latest/components/realm-managem…
My observation is running plainly the model, everything looks ok, the VFP
can run the SW without any problem. (I can see the consol windows with
normal booting procedure)
In case I would like to set up the ARM debugger in ARM DS, the simulation
immediately stops after start with a popup window: "Unable to connect to
device ARMAEM-a_MP_0 Error opening connection to device 16 Socket is
closed(E_io_error) Socket is closed"
Apparently my Debug settings are good: With the same settings I can
run/debug the complete ARM Reference Solution (Linux, u-boot,
TrustedFirmware) based on this description:
https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs…
but if I add additional flags for FVP: (-C cluster0.rme_support_level=2 -C
cluster1.rme_support_level=2) I still can run the model, but cannot debug
so when I activate the RME feature the ARM debugger do the previously
mentioned behavior (stops right after start)
How can I workaround this? What is the most efficient way to debug FVP with
RME support. Any help is welcome here.
Bye,
Adam
Hi Xin,
I my opion, it should base on product lifecyle phase.
In development phase, the SW engineer can use dev ROT keys & certificates. ATF have tools to generate them.
In deployment stage, use KMI to manage keys&certificates are more better.
BRs,Ben
----------回复的邮件信息----------
Xin.Xu--- via TF-A<tf-a(a)lists.trustedfirmware.xn--org> 2022-10-19-jw84b 周三 23:56写道:
product ROT private key is controlled by KMI team.
our plan is
(1) SW build engineer builds tf-a with a temporary development ROT key, save all other generated keys
(2) remove fip image and all certificates built, send build images and generated keys to KMI team
(3) KMI team uses cert_create to re-generate all certificates with product ROTK
(4) KMI team sends all images, certificates, ROTPK hash to SW build engineer
(5) SW build engineer uses fiptool to generate final fip image
my question: is there a better way to deal with this situation? (SW build engineer doesn't have control of ROT key)
Thanks
-Xin
--
TF-A mailing list -- tf-a(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org
This event has been canceled with a note:
"As indicated on the TF-A ML no topics this week so cancelling. Joanna"
TF-A Tech Forum
Thursday Oct 20, 2022 ⋅ 4pm – 5pm
United Kingdom Time
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/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One 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
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
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 All,
In the calendar we have a TF-A Tech Forum for this Thursday. I currently have no topic for discussion.
If anybody in the community has a topic please let me know by Wednesday this week otherwise I will cancel.
Thanks
Joanna
product ROT private key is controlled by KMI team.
our plan is
(1) SW build engineer builds tf-a with a temporary development ROT key, save all other generated keys
(2) remove fip image and all certificates built, send build images and generated keys to KMI team
(3) KMI team uses cert_create to re-generate all certificates with product ROTK
(4) KMI team sends all images, certificates, ROTPK hash to SW build engineer
(5) SW build engineer uses fiptool to generate final fip image
my question: is there a better way to deal with this situation? (SW build engineer doesn't have control of ROT key)
Thanks
-Xin
Hi All,
As TF is moving forward with a TF-A LTS per the proposals that have been
presented, I've created a new mail list for this purpose.
Please feel free to subscribe.
https://lists.trustedfirmware.org/mailman3/lists/tfa-lts.lists.trustedfirmw…
Thanks,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org