Hello,
As announced in the last Tech forum, the code freeze date for the LTS branch is Feb 3, 2023. We have started shortlisting the patches for the lts-v2.8 branch.
These are the commits that will be merged into the LTS branch. More details can be found at ⚡ LTS Tracking for v2.8.x (trustedfirmware.org)<https://developer.trustedfirmware.org/w/tf_a/tf-a_lts_meeting_minutes/track…>
1. c7e698cfd fix(cpus): workaround for Cortex-X3 erratum 2615812
2. c45791b2f fix(layerscape): fix errata a008850
3. fa0105693 fix(nxp-ddr): use CDDWW for write to read delay
4. 00bb8c37e fix(nxp-ddr): apply Max CDD values for warm boot
5. 07d8e34fd fix(nxp-drivers): fix tzc380 memory regions config
6. c0c157a68 fix(ls1046a): 4 keys secureboot failure resolved
7. 50aa0ea7a fix(lx2): init global data before using it
8. 4daeaf341 fix(sptool): add dependency to SP image
9. 5fb6946ad fix(console): fix crash on spin_unlock with cache disabled
10. ff1d2ef38 fix(el3_runtime): restore SPSR/ELR/SCR after esb
11. c42402cdf fix(intel): fix fcs_client crashed when increased param size
12. 0ca1d8fba fix(layerscape): unlock write access SMMU_CBn_ACTLR
13. b87b02cf1 fix(cpus): workaround for Cortex-A710 erratum 2768515
14. 1cfde8222 fix(cpus): workaround for Cortex-X2 erratum 2768515
15. 377846b65 fix(st): include utils.h to solve compilation error
16. 1cbe42a51 fix(el3_runtime): allow SErrors when executing in EL3
17. 1ee7c8232 fix(cpus): workaround for Neoverse N2 erratum 2743089
18. b10afcce5 fix(cpus): workaround for Cortex-A78 erratum 2772019
19. 31747f057 fix(cpus): workaround for Neoverse V1 erratum 2743093
20. fd37982a1 fix(auth): forbid junk after extensions
21. 72460f50e fix(auth): require at least one extension to be present
22. 06c01b085 fix(libc): properly define SCHAR_MIN
23. 89d85ad0a fix(cpus): workaround for Cortex-A710 erratum 2282622
24. abb8f936f fix(auth): avoid out-of-bounds read in auth_nvctr()
25. f5c51855d fix(auth): properly validate X.509 extensions
26. f9c6301d7 fix(cpus): workaround for Cortex-X2 erratum 2282622
27. 60719e4e0 fix(plat/css): fix invalid redistributor poweroff
28. 00230e37e fix(cpus): workaround for Cortex-A78C erratum 2772121
29. aea4ccf8d fix(cpus): workaround for Cortex-A510 erratum 2684597
If there are commits that we missed or that need to be in the LTS branch, please reach out to us.
Thanks.
This event has been updated
Changed: description
TF-A Tech Forum
Thursday Jan 26, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Apologies the LTS Update is for this week on 26th January at 4pm GMT Not
February session.=====Just a reminder that this week the TF-A Tech Forum is
covering a LTS Release update session from the primary maintainers of the
TF-A v2.8 LTS branch:Varun WadekarOkash Khawaja Bipin Ravi Thanks
AllJoanna========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://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
bpeckham(a)google.com
mayurvg(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
This event has been updated
Changed: description
TF-A Tech Forum
Thursday Feb 23, 2023 ⋅ 4pm – 5pm
United Kingdom Time
Just a reminder that this week the TF-A Tech Forum is covering a LTS
Release update session from the primary maintainers of the TF-A v2.8 LTS
branch:Varun Wadekar <vwadekar(a)nvidia.com> Okash Khawaja
<okash(a)google.com> Bipin Ravi <Bipin.Ravi(a)arm.com>Thanks
AllJoanna===============================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://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 All,
We are in the process of migrating from mbedtls-2.28 support to 3.3 support
we plan to deprecate mbedtls-2.28 support for TF-A 3.0 Release
but would retain support for both 2.28 and 3.3 for TF-A 2.9 lifetime.
There is draft implementation available[1] for code review
which cleanups and prepares for mbedtls-3.3 support but retaining backward
compatibility for mbedtls-2.28.
Please let us know if there any objections to deprecation of mbedtls-2.28 in
TF-A 3.0.
--
Thanks
Govindraj
[1]: https://review.trustedfirmware.org/q/topic:%2522mbedtls3.3_support%2522
<https://review.trustedfirmware.org/q/topic:%2522mbedtls3.3_support%2522>
Hi,
Happy new year!
For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value.
I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement.
Thoughts?
-Varun
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.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 382954: Concurrent data access violations (MISSING_LOCK)
/plat/mediatek/drivers/spm/mt8188/constraints/mt_spm_rc_cpu_buck_ldo.c: 173 in spm_get_status_rc_cpu_buck_ldo()
________________________________________________________________________________________________________
*** CID 382954: Concurrent data access violations (MISSING_LOCK)
/plat/mediatek/drivers/spm/mt8188/constraints/mt_spm_rc_cpu_buck_ldo.c: 173 in spm_get_status_rc_cpu_buck_ldo()
167 dest = (struct constraint_status *)st->value;
168 do {
169 if (dest == NULL) {
170 break;
171 }
172 if (st->type == CONSTRAINT_GET_VALID) {
>>> CID 382954: Concurrent data access violations (MISSING_LOCK)
>>> Accessing "dest->is_valid" without holding lock "spm_lock". Elsewhere, "constraint_status.is_valid" is accessed with "spm_lock" held 5 out of 6 times.
173 dest->is_valid = cpubuckldo_status;
174 } else if (st->type == CONSTRAINT_COND_BLOCK) {
175 dest->is_cond_block = 0;
176 } else if (st->type == CONSTRAINT_GET_ENTER_CNT) {
177 if (st->id == MT_RM_CONSTRAINT_ID_ALL) {
178 dest->enter_cnt += cpubuckldo_enter_cnt;
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
Hi,
The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way
of post-boot loading OP-TEE by the Linux kernel with signature
verification in the normal world only. This has previously been
discussed in this mail thread [2] about half a year ago. Ultimately,
it was concluded that this should in principle be accepted upstream as
a platform choice to allow this or not. There are concerns that what
we have in upstream TF-A should serve as good examples, and trusting
the normal world to verify secure world software might not meet that
criterion. There are also concerns about adding signature verification
to BL31
Leaving the secure world wide open until the Linux kernel has been
able to successfully load and verify an OP-TEE binary seems very
risky. Even if it's claimed that the normal world can be trusted at
this point, we're still giving up a critical level of defense without
a good reason.
I've started to review [1], but it should not be accepted for merging
without support and approval from other maintainers.
I would like to explore other options in this mail thread. In [2] it
was suggested that a remnant of bl2 could be kept to verify OP-TEE
before starting to execute it. This could be taken one step further
and load a limited OP-TEE at boot which later is updated live, almost
like what's discussed in [3]. This should minimize the impact on TF-A
and also leave OP-TEE in charge of accepting an update instead of a
divided responsibility between the normal world and TF-A.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635
[2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
[3] https://github.com/OP-TEE/optee_os/issues/5699
Thanks,
Jens
Hello everyone,
A new security vulnerability has been identified in TF-A X.509 parser,
used for trusted boot in BL1 and BL2.
Please note that this vulnerability is *not* exploitable in TF-A
upstream code. Only downstream code might be affected under specific
circumstances.
The security advisory has been published in TF-A documentation and has
all the details:
https://trustedfirmware-a.readthedocs.io/en/latest/security_advisories/secu…
Patches to fix the identified bugs have already been merged in TF-A
tree. The advisory lists the relevant patches.
I would like to thank Demi Marie Obenour from Invisible Things Lab for
responsibly disclosing this security vulnerability to
TrustedFirmware.org, for providing patches to fix the identified bugs
and further harden the X.509 parser, for providing a detailed impact
analysis and for helping put this security advisory together.
Best regards,
Sandrine Bailleux, on behalf of TF-A security team.
This event has been updated with a note:
"Correcting the deletion of the wrong Techforum."
Changed: time
TF-A Tech Forum
Thursday Jan 26, 2023 ⋅ 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
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
This event has been canceled with a note:
"No topic this week. Cancelling. Joanna"
TF-A Tech Forum
Thursday Jan 26, 2023 ⋅ 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,
With the start of the new year I’m looking to see what TF-A Techforums should cover over the next few sessions. As folks may know these are held every two weeks on a Thursday at 4pm GMT. If you need an invite do reach out to me.
If folks have anything they would like to present to the TF-A community please do reach out to me as we often need topics. If we don’t have anything to present on upcoming sessions I will cancel the sessions the day before they are due to be held.
Currently I tentatively have the following for the first 4 sessions which will be confirmed nearer the dates:
* 12th January – No topic
* 26th January – LTS Update
* 9th February – No topic
* 23rd February - Tech talk for PSCI OS-initiated mode
Thanks
Joanna
Hello,
I'm working on a project for ChromeOS where we would like to be able to
load the BL32 payload (OpTee) for SEL-1 after the linux kernel has booted
rather than during the usual BL32 stage. We would do this via an SMC we
would add which would take the OpTee image from linux and then have EL3
load it and perform the init for SEL-1 at that time.
The reasoning behind this is that it's much easier to update the rootfs
than the FW on our devices, and we can still ensure the integrity of the
OpTee image if we load it early enough after the kernel boots.
The main questions I have are if there are any issues people would be aware
of by loading it after linux boots rather than during the usual BL32 stage?
And I would definitely want to upstream this work if it's something we can
do.
Thanks,
Jeffrey Kardatzke
Google, Inc.
Hi all,
I test the SMMUv3 on FVP_Base_RevC-2xAEMvA_11.20_15, and my TF-A is
the branch "arm_cca_v0.3".
When I boot my FVP, I set the following commands:
-C pci.pci_smmuv3.mmu.SMMU_ROOT_IDR0=3 \
-C pci.pci_smmuv3.mmu.SMMU_ROOT_IIDR=0x43B \
-C pci.pci_smmuv3.mmu.root_register_page_offset=0x20000 \
-C cluster0.rme_support_level=2 \
-C cluster1.rme_support_level=2 \
Based on the FVP manual, the SMMU base is 0x2b40_0000, and I think the
SMMU Root Control Page should be 0x2b42_0000.
Thus, I add the mapping to this region in plat_arm_mmap[], as:
MAP_REGION_FLAT(0x2b420000,(0x2b430000-0x2b420000),MT_MEMORY | MT_RW |MT_ROOT)
Then I try to access the SMMU_ROOT_IDR0 register in TF-A. Based on
the manual, its offset is 0x0, so I read 0x2b42_0000.
However, it returns 0x0, which is not what I configured in the boot
commands (I think it should be 0x3).
Can someone tell me the reason for this?
Sincerely,
WANG Chenxu
Hello everyone,
I'd like to draw your attention on the following patch stack
(contribution from Demi Marie Obenour, thank you!):
https://review.trustedfirmware.org/q/owner:demiobenour%2540gmail.com+is:open
These patches refactor the X.509 certificate parser leveraged by the
trusted boot implementation in TF-A, such that the parser more closely
follows the X.509 format specification [1] and ASN.1/DER encoding rules [2].
In a nutshell, this means that the X.509 parser is now stricter. Some
ill-formatted certificates which TF-A would have previously accepted are
now rejected.
All trusted boot tests in the TF-A OpenCI have passed with these patches
but I realize that this does not cover all platforms and use cases.
Thus, I'd like to allow time for all platform maintainers that wish it
to conduct their own testing and report any issue they're seeing on the
mailing list. If we don't hear anything by end of Wednesday (14/12),
we'll merge the patches.
Best regards,
Sandrine
[1] See RFC5280, https://datatracker.ietf.org/doc/html/rfc5280
[2] ITU-T X.690,
https://www.itu.int/ITU-T/studygroups/com10/languages/X.690_1297.pdf
Hi all,
We are pleased to announce that the Trusted Services project has made the first tagged public release, v1.0.0-beta.
The release includes Trusted Services which can be deployed on Cortex-A devices to meet PSA Certified requirements. The release also includes necessary build and test infrastructure and documentation.
The release includes:
* PSA Crypto, Storage and Attestation Secure Partitions exposing the PSA Certified Functional APIs, the same APIs available today on Arm v8-M Cortex-M platforms via Trusted Firmware-M.
* Additionally, UEFI SMM services are available through the SMM Gateway Secure Partition.
* The services within the Secure Partitions can be invoked by applications for secure operations.
* OP-TEE in 3.17 and later releases support Secure Partition Manager Core (SPMC). Details can be found here<https://developer.trustedfirmware.org/w/trusted-services/op-tee-spmc/>. This release was validated with OP-TEE v3.19
For more information, please refer to the following resources:
* Change log and release notes: https://trusted-services.readthedocs.io/en/v1.0.0-beta/project/change-log.h…
* Documentation: https://trusted-services.readthedocs.io/en/v1.0.0-beta/
* Source code: https://git.trustedfirmware.org/TS/trusted-services.git/tag/?h=v1.0.0-beta
* Test results including information on the set-up tests were executed with: https://developer.trustedfirmware.org/w/trusted-services/test-reports/v1.0.…
* Roadmap for future development: https://developer.trustedfirmware.org/w/trusted-services/roadmap
If you have any questions or comments do not hesitate to contact us via the mailing list, or by dropping an email to Shebu.VargheseKuriakose(a)arm.com<mailto:Shebu.VargheseKuriakose@arm.com> or gyorgy.szing(a)arm.com<mailto:gyorgy.szing@arm.com>.
Kind Regards
György Szing
Hi All,
I’m cancelling the TF-A Techforum for this Thursday as we have no topic.
However, we do plan a session for 15th December.
Following the recent addition of QEMU support in TF-A OpenCI [1], we'd like to:
Do a quick demo on how to navigate the OpenCI services (Jenkins, LAVA) and find the QEMU boot tests results.
* Possibly do a quick demo on how to run these tests on your local machine through TF-A CI scripts.
* Give a high-level overview of the changes in TF-A CI scripts and OpenCI infrastructure that made this possible.Following the recent addition of QEMU support in TF-A OpenCI [1], we'd like to:
[1] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…<https://www.google.com/url?q=https://lists.trustedfirmware.org/archives/lis…>
Joanna
This event has been updated with a note:
"Update for subject on 15th December TF-A Tech Forum"
Changed: description
TF-A Tech Forum
Thursday Dec 15, 2022 ⋅ 4pm – 5pm
United Kingdom Time
NOTE this is for 15th December 2022Following the recent addition of QEMU
support in TF-A OpenCI [1], we'd like to:Do a quick demo on how to navigate
the OpenCI services (Jenkins, LAVA) and find the QEMU boot tests
results.Possibly do a quick demo on how to run these tests on your local
machine through TF-A CI scripts.Give a high-level overview of the changes
in TF-A CI scripts and OpenCI infrastructure that made this
possible.Following the recent addition of QEMU support in TF-A OpenCI [1],
we'd like
to:[1] https://lists.trustedfirmware.org/archives/list/tf-a@list…
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
This event has been canceled with a note:
"No topics this week so cancelling. We do have a topic for 2 weeks time on
15th December."
TF-A Tech Forum
Thursday Dec 1, 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
Current code skips load of spinlock address when cache is disabled. The
following call to spin_unlock stores into the random location that x0
points to.
Move spinlock address load earlier so that x0 is always valid on
spin_unlock call.
Change-Id: Iac640289725dce2518f2fed483d7d36ca748ffe8
Signed-off-by: Baruch Siach <baruch(a)tkos.co.il>
---
I'm posting this patch here since I have found no way to upload to
review.trustedfirmware.org. I logged in via github, but I can not add
SSH keys ("New SSH Key" grayed out), and "GENERATE NEW PASSWORD" shows
Error 500.
Hope this is not too wrong.
---
plat/common/aarch64/crash_console_helpers.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/plat/common/aarch64/crash_console_helpers.S b/plat/common/aarch64/crash_console_helpers.S
index e2950f5f7c55..75b420893325 100644
--- a/plat/common/aarch64/crash_console_helpers.S
+++ b/plat/common/aarch64/crash_console_helpers.S
@@ -68,12 +68,12 @@ func plat_crash_console_init
mov x4, x30 /* x3 and x4 are not clobbered by spin_lock() */
mov x3, #0 /* return value */
+ adrp x0, crash_console_spinlock
+ add x0, x0, :lo12:crash_console_spinlock
+
mrs x1, sctlr_el3
tst x1, #SCTLR_C_BIT
beq skip_spinlock /* can't synchronize when cache disabled */
-
- adrp x0, crash_console_spinlock
- add x0, x0, :lo12:crash_console_spinlock
bl spin_lock
skip_spinlock:
--
2.35.1
Hello everyone,
Following our recent release, I'm pleased to provide more details on recent
developments in our CI for QEMU.
Linaro’s continuous integration platform OpenCI supports running emulated tests
on QEMU. The tests are kicked off on Jenkins and deployed through the Linaro
Automation and Validation Architecture LAVA. The obvious benefit of this is it
makes it relatively easy to test TF-A in CI without a complex hardware setup, much
like we do with FVPs. For this reason, we have added scripts to our OpenCI scripts
repository to enable running this form of automated tests on QEMU.
The initial patches provide a set of end-to-end boot tests (TF-A -> Linux shell
prompt) that are included in our daily job [1]. The long term plan is
to use this and further QEMU tests to gate patch submission (CI +1, +2),
however, this is will only happen when we have confidence in their stability.
You can view a sample test run here [2].
You can also reproduce the test setup manually in OpenCI or locally. In OpenCI
this is done by running the tf-a-builder job with `qemu-boot-tests` as the test
group [3]. In your local setup, this is done with the following command line:
```
$ test_run=1 \
workspace=$(mktemp -d) \
nfs_volume="$workspace"
tfa_downloads="https://downloads.trustedfirmware.org/tf-a"
tf_root="/path/to/trusted-firmware-a/" \
tftf_root="/path/to/tf-a-tests/" \
test_groups="qemu-boot-tests/qemu-default:qemu-linux.rootfs-fip.uefi-virt" \
bash -x $ci_root/script/run_local_ci.sh
```
We highly encourage you to contribute to the QEMU CI scripts if you can!
Whether that be helping extend the tests or providing enhancements. We are
also looking for help maintaining this specific area and the infrastructure
around it - if this of interest, please do reach out!
Cheers!
Harrison
[1] https://ci.trustedfirmware.org/job/tf-a-main
[2] https://tf.validation.linaro.org/scheduler/job/1168495
[3] https://ci.trustedfirmware.org/job/tf-a-builder/
Hello,
Just following up on my question regarding HSMs (pasted below). Do any of the maintainers of cert_create have feedback on this? Thanks!
-Brian
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#L5...). 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?