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?
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
Hello everyone,
There is a type of errata on a few CPUs where if they initiate a power
down request which gets denied then attempting to power down again can
fail in a deadlock. In essence, after the PE's power down sequence which
ends on a WFI, but before actual power down, there exists a small window
where an external event can interrupt the power down and cause the PE to
continue after the WFI. Attempting to power down again after that can
result in a deadlock.
Affected CPUs are the Neoverse N2, Makalu ELP (Cortex X3), and Cortex A710.
The SDEN [1] suggests to set the chicken bit CPUACTLR2_EL1[36] before
the power down sequence and to clear it after coming out of the WFI (on
anything other than RESET). The mitigations [2] set the bit in the
`core_pwr_dwn` of each CPU but never clear it. This is because in the
generic TF-A code path the WFI ends up being called in an infinite loop
with the only way to come out of it being RESET. Most platforms with
custom `pwr_domain_pwr_down_wfi` end up in the same loop or unrelated
hardware reset mechanisms that avoid the errata. However, a few
platforms could continue running as normal without going through a
hardware reset which would require special treatment.
The four problematic platforms are:
* amlogic gxl and g12a: they fake a reset by manually calling the reset
entrypoint on their primary CPUs only. This will leave the chicken bit
set after reset.
* socionext uniphier: same as amlogic but on all CPUs.
* nxp (common code): I hope I understand what the platform is trying to
do but there are 2 paths that raise an eyebrow: `_psci_sys_pwrdn_wfi`
which has a single non-looped wfi (which could return as above) and
`_psci_cpu_off_wfi` which seems to accept waking up as normal behaviour.
The former path is a simple fix but the latter is the same case as
amlogic and socionext. Due to its complexity I have not proposed any
modification on either path.
Finally, nvidia tegra and renesas (common code) have acceptable
behaviour as far as the errata are concerned, however, they end up in
the wfi loop only after a panic sequence. Although not problematic, this
stands out.
For all six platforms above there are a few options on how to proceed,
the preferred one being to bring them in line with what everyone else
does. Alternatively, ignoring the errata would be ok if these platforms
never intend to use these CPUs. It must be noted, however, that it
appears to be a family of errata, and these may not be all CPUs affected.
[1]: the wording is identical for all 3 cores. For Neoverse N2:
https://developer.arm.com/documentation/SDEN1982442/latest/
[2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17157/1
Regards,
Boyan
This event has been canceled with a note:
"No topics arranged for this week so cancelling. At this time we don't have
a topic for 20th September either. Something may well appear before then
from Arm however if anybody in the broader community has a topic they would
like to present please reach out me (Joanna.farley(a)arm.com)."
TF-A Tech Forum
Thursday Oct 6, 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,
With the RME feature BL2 has to run at EL3 instead of EL1_S. EL3 has a
separate PAS not accessible to EL1_S.
Is there any harm in choosing to run BL2 at EL3 instead of BL2 at S_EL1
even for non-RME(v8a) systems? Given that EL3 and EL1_S have access to the
same PAS. I am trying to revisit the motivation to run BL2 at EL1_S.
I see there was an old discussion at
https://github.com/ARM-software/tf-issues/issues/445 The reasoning was not
pointing to any issue in specific but a generic principle of less
permissiveness.
Thanks
Sandeep
Hi Manish,
>>The existing name is more suitable for configuration where the platform has BL1 in it and BL2 can run at EL3 instead of S-EL1.
Well, that is a minor thing to take care. V9 implementation does that in a way.
>>This configuration is currently not available in TF-A but having this flexibility is not a bad idea and it can be platform's choice.
That's my answer! And the default choice costs some memory with probably no increase in security (V8).
>>BL31 can mask the secure world.
Cant be done reliably on V8 (with root world V9 or EL2_S there is potential to compartmentalize the secure services as PAS isolation is feasible)
Ex: EL1S can always overwrite the BL31 Xlat tables and take control of the vectors and many other ways depending on the platform. It's the same PAS!
Thanks
Sandeep
According to the Generic Names Recommendation in the Devicetree
Specification Release v0.3, and the DT Bindings for the Renesas Reduced
Pin Count Interface, the node name for a Renesas RPC-IF device should be
"spi". The node name matters, as the node is enabled by passing a DT
fragment from TF-A to subsequent software.
Fix this by renaming the device nodes from "rpc" to "spi".
Fixes: 12c75c8886a0ee69 ("feat(plat/rcar3): emit RPC status to DT fragment if RPC unlocked")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
---
Background:
On Renesas R-Car Gen3 platforms, the SPI Multi I/O Bus Controllers
(RPC-IF) provide access to HyperFlash or QSPI storage. On production
systems, they are typically locked by the TF-A firmware, unless TF-A is
built with RCAR_RPC_HYPERFLASH_LOCKED=0. When unlocked, TF-A
communicates this to subsequent software by passing a DT fragment that
sets the "status" property of the RPC-IF device node to "okay".
Unfortunately there are several issues preventing this from working all
the way to Linux:
1. TF-A (and U-Boot on the receiving side) uses a device node name
that does not conform to the DT specification nor the DT bindings
for RPC-IF,
2. While U-Boot receives the RPC-IF enablement from TF-A, it does not
propagate it to Linux yet,
3. The DTS files that are part of Linux do not have RPC HyperFlash
support yet.
This patch takes care of the first issue in TF-A.
The related patches for U-Boot are [1].
Patches to enable RPC-IF support in Linux are available at [2].
Thanks for your comments!
[1] "[PATCH u-boot 0/3] renesas: Fix RPC-IF enablement"
https://lore.kernel.org/r/cover.1648544792.git.geert+renesas@glider.be
[2] "[PATCH 0/5] arm64: dts: renesas: rcar-gen3: Enable HyperFlash support"
https://lore.kernel.org/r/cover.1648548339.git.geert+renesas@glider.be
---
plat/renesas/rcar/bl2_plat_setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plat/renesas/rcar/bl2_plat_setup.c b/plat/renesas/rcar/bl2_plat_setup.c
index bbfa16927d6c2384..f85db8d650c6b1a5 100644
--- a/plat/renesas/rcar/bl2_plat_setup.c
+++ b/plat/renesas/rcar/bl2_plat_setup.c
@@ -574,7 +574,7 @@ static void bl2_add_rpc_node(void)
goto err;
}
- node = ret = fdt_add_subnode(fdt, node, "rpc@ee200000");
+ node = ret = fdt_add_subnode(fdt, node, "spi@ee200000");
if (ret < 0) {
goto err;
}
--
2.25.1
Hi,
As you may know, the build system was changed, and the tip of master depends on Openssl3. This version is quite new and is not available in many old (or not so old) but still supported operating systems. (Ubuntu 18.04 is an example.)
I made a quick and dirty fix to allow building Opessl3 right from TF-A if the source is pre-fetched. You can find this change here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16800 For our downstream project this is a perfect solution as the same component introducing the new dependency carries the solution. Thus, my build environment is not becoming TF-A version specific.
From TF-A point of view the situation is not so simple. The above patch extends TF-A with "build environment provisioning" responsibility. Before this patch TF-A assumed, all "common" dependencies are available in the build environment, and this patch changes that. Yes, some strongly TF-A specific components were owned and built by TF-A, but openssl is different.
Thus, my modification is a "game changer" in some ways. A few things to consider:
* Openssl becomes a special kind of TPIP which the project will need to manage (e.g. look for security risks, version updates, compatibility to different OSs and OS versions, etc...).
* This is a system wide component. There is a risk of breaking something the build uses. Hidden things like a python module depending on openssl and now picking up an incompatible version.
* This change might be considered as layer bleeding since it "melds" responsibilities of the TF-A project and the "owner of the build environment". IMHO this might be a significant difference from supply-chain security perspectives.
There are alternatives which might be considered better:
* making the build system and host side tooling (e.g. cert_tool) backwards compatible with openssl2
* hosting pre-built static binaries somewhere, which would simplify build environment updates
As I mentioned above, this is a "good enough" fix for my use-case, but not sure if this is the right approach from TF-A perspectives.
I am happy to tidy up this patch and push it trough the review, but the efforts needed to implement "other options" are beyond my capacity.
I am looking for feedback both from TF-A maintainers and from "build environment owners". Thanks!
/George
Ps.: Apologies for not doing "my homework". I know there is a ticket somewhere in Phabricator and I did not invest the needed time to find it.
TL;DR: Attached is the TF-A LTS proposal doc. Please review and share
your thoughts.
Hello everyone,
Long term support for TF-A has a long history. As a community we have
flirted with it for a while, and like any flirtation, it started with
gossip -- in our case, over mailing list [1] -- more than two years
ago. Then Varun Wadekar did a wonderful tech forum presentation [2]
which demonstrated interest in the topic and raised interesting
questions about LTS.
After some time, the affair lost headline status, only to be revived
again [3], earlier this year. This time however, there is a formal
proposal (no pun intended). After the mailing list discussion and
feedback from TF-A tech forum [4], we have put together a draft which
attempts to give a concrete idea about what the TF-A LTS will look
like.
Please spare some time to read through it and share your feedback. The
plan is to put LTS into action this November.
Cheers!
Okash
[1] https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…
[2] https://www.trustedfirmware.org/docs/TF-A-LTS.pdf
[3] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
[4] https://www.trustedfirmware.org/docs/TForg_LTS_proposal.pdf
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 370380: Code maintainability issues (UNUSED_VALUE)
/plat/xilinx/versal/pm_service/pm_svc_main.c: 128 in pm_setup()
________________________________________________________________________________________________________
*** CID 370380: Code maintainability issues (UNUSED_VALUE)
/plat/xilinx/versal/pm_service/pm_svc_main.c: 128 in pm_setup()
122 int32_t status, ret = 0;
123
124 status = pm_ipi_init(primary_proc);
125
126 if (status < 0) {
127 INFO("BL31: PM Service Init Failed, Error Code %d!\n", status);
>>> CID 370380: Code maintainability issues (UNUSED_VALUE)
>>> Assigning value from "status" to "ret" here, but that stored value is overwritten before it can be used.
128 ret = status;
129 } else {
130 pm_up = true;
131 }
132
133 /*
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
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.
1 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 380957: Integer handling issues (NO_EFFECT)
/drivers/arm/gic/v3/gicv3_main.c: 1109 in gicv3_raise_sgi()
________________________________________________________________________________________________________
*** CID 380957: Integer handling issues (NO_EFFECT)
/drivers/arm/gic/v3/gicv3_main.c: 1109 in gicv3_raise_sgi()
1103 u_register_t target)
1104 {
1105 unsigned int tgt, aff3, aff2, aff1, aff0;
1106 uint64_t sgi_val;
1107
1108 /* Verify interrupt number is in the SGI range */
>>> CID 380957: Integer handling issues (NO_EFFECT)
>>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "sgi_num >= 0U".
1109 assert((sgi_num >= MIN_SGI_ID) && (sgi_num < MIN_PPI_ID));
1110
1111 /* Extract affinity fields from target */
1112 aff0 = MPIDR_AFFLVL0_VAL(target);
1113 aff1 = MPIDR_AFFLVL1_VAL(target);
1114 aff2 = MPIDR_AFFLVL2_VAL(target);
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
This event has been updated with a note:
"Firmer Agenda for 22md Sept session"
Changed: description
TF-A Tech Forum
Thursday Sep 22, 2022 ⋅ 4pm – 5pm
United Kingdom Time
Agenda for Techforum session on Sept 22nd 2022Firmware update
implementation in Total Compute (TC) Arm Reference Software Stack[1]:Brief
overview of Firmware update mechanism as per the Firmware update
specification [2]Implementation of FWU specification in Total
ComputeDiscuss partner's view on this mechanismPresenter: Davidson
Kumaresan and Manish
Badarkhe[1] https://developer.arm.com/Tools%20and%20Software/Total%20C…
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
Okash Khawaja
santantonioswap(a)gmail.com
don.harbin(a)linaro.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,
Sorry if this is the wrong list, I'm trying to submit a patch for tf-a and
I'm currently unable to add an ssh key or generate an https password to use
for authentication.
Perhaps I am doing something wrong?
I'm trying to use the settings here:
https://review.trustedfirmware.org/settings/#HTTPCredentials to add an ssh
key and I get the error message
"Error 500 (Server Error): Internal server error Endpoint:
/accounts/self/sshkeys"
Any help is greatly appreciated.
Thanks,
Scott (sparlane)
This event has been updated with a note:
"We have a proposed subject for this TF-A Tech Forum. Joanna"
Changed: description
TF-A Tech Forum
Thursday Sep 22, 2022 ⋅ 4pm – 5pm
United Kingdom Time
Proposed session for this Tech Forum will be an update to Firmware Update
capabilities.More details to follow.....------------------------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 updated with a note:
"Updated Agenda for 8th September session."
Changed: description
TF-A Tech Forum
Thursday Sep 8, 2022 ⋅ 4pm – 5pm
United Kingdom Time
The plan is to use this Tech Forum session to discuss the LTS proposal and
review comments received.See the TF-A Mailing list for details of the
proposal and review
comments: https://lists.trustedfirmware.org/archives/list/tf-a@lists.t…
will be led by Okash Khawaja and Varun Wadekar.ThanksJoanna
Farley-------------------------------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 all,
I want to test how to trap the aborts caused by TZASC.
For example, when I use NS-EL1 (e.g., OS) to access a Secure region
(configured in TZASC), it will generate an abort.
But I am not sure how to trap it. I think it is an external abort, so
I enable the SCR_EL3.EA=1 and write a handler. However I cannot trap
it. Also, my other handlers in EL3 still do not report the abort.
Thus, how can I trap a TZASC abort? If I want to route it into EL3 to
handle, how can I do it?
Sincerely,
WANG Chenxu
Hi,
Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
1 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 3 of 3 defect(s)
** CID 380536: Control flow issues (NO_EFFECT)
/bl32/tsp/tsp_ffa_main.c: 220 in test_memory_send()
________________________________________________________________________________________________________
*** CID 380536: Control flow issues (NO_EFFECT)
/bl32/tsp/tsp_ffa_main.c: 220 in test_memory_send()
214 ERROR("Failed [%u] mmap_add_dynamic_region %u (%lx) (%lx) (%x)!\n",
215 i, ret,
216 (uint64_t)composite->address_range_array[i].address,
217 size, mem_attrs);
218
219 /* Remove mappings created in this transaction. */
>>> CID 380536: Control flow issues (NO_EFFECT)
>>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "i >= 0U".
220 for (i--; i >= 0U; i--) {
221 ret = mmap_remove_dynamic_region(
222 (uint64_t)ptr,
223 composite->address_range_array[i].page_count * PAGE_SIZE);
224
225 if (ret != 0) {
** CID 380535: Null pointer dereferences (REVERSE_INULL)
/bl32/tsp/ffa_helpers.c: 154 in memory_retrieve()
________________________________________________________________________________________________________
*** CID 380535: Null pointer dereferences (REVERSE_INULL)
/bl32/tsp/ffa_helpers.c: 154 in memory_retrieve()
148 uint32_t *total_length)
149 {
150 smc_args_t ret;
151 uint32_t descriptor_size;
152 struct ffa_mtd *memory_region = (struct ffa_mtd *)mb->tx_buffer;
153
>>> CID 380535: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "mb" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
154 if (retrieved == NULL || mb == NULL) {
155 ERROR("Invalid parameters!\n");
156 return false;
157 }
158
159 /* Clear TX buffer. */
** CID 380534: API usage errors (SWAPPED_ARGUMENTS)
________________________________________________________________________________________________________
*** CID 380534: API usage errors (SWAPPED_ARGUMENTS)
/bl32/tsp/tsp_ffa_main.c: 476 in handle_partition_message()
470
471 default:
472 INFO("TSP Tests: Unknown request ID %d--\n", (int) arg3);
473 }
474
475 /* Swap the sender and receiver in the response. */
>>> CID 380534: API usage errors (SWAPPED_ARGUMENTS)
>>> The positions of arguments in the call to "ffa_msg_send_direct_resp" do not match the ordering of the parameters:
* "receiver" is passed to "sender".
* "sender" is passed to "receiver".
476 return ffa_msg_send_direct_resp(receiver, sender, status, 0, 0, 0, 0);
477 }
478
479 /*******************************************************************************
480 * This function implements the event loop for handling FF-A ABI invocations.
481 ******************************************************************************/
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
This event has been canceled with a note:
"Apologies for the short notice. We have no topic this week and some key
folks are out on vacations. I'm hoping the Techforum on the 8th September
can be a followup LTS discussion on the proposal submitted to the Mailing
list. I'll formally organise that for the 8th next week."
TF-A Tech Forum
Thursday Aug 25, 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