- TF-A - lists.trustedfirmware.org

[PATCH 1/1] plat/qemu: Improve aarch32 build support

by Rebecca Cran

While aarch32 isn't currently supported on qemu, platform.mk for both qemu and qemu_sbsa contain bugs that cause the build to fail earlier than it otherwise should. Correct usage of ${ARCH} and hardcoded aarch64 strings so that the correct files are built when ARCH=aarch32 is specified. Signed-off-by: Rebecca Cran <rebecca(a)quicinc.com> --- plat/qemu/qemu/platform.mk | 12 ++++++------ plat/qemu/qemu_sbsa/platform.mk | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/plat/qemu/qemu/platform.mk b/plat/qemu/qemu/platform.mk index dfc5de2ce43a..7b69ff76f3d6 100644 --- a/plat/qemu/qemu/platform.mk +++ b/plat/qemu/qemu/platform.mk @@ -45,7 +45,7 @@ PLAT_INCLUDES := -Iinclude/plat/arm/common/ \ -Iinclude/common/tbbr ifeq (${ARM_ARCH_MAJOR},8) -PLAT_INCLUDES += -Iinclude/plat/arm/common/${ARCH} +PLAT_INCLUDES += -Iinclude/plat/arm/common/aarch64 endif PLAT_BL_COMMON_SOURCES := ${PLAT_QEMU_COMMON_PATH}/qemu_common.c \ @@ -138,11 +138,11 @@ BL1_SOURCES += drivers/io/io_semihosting.c \ ${PLAT_QEMU_COMMON_PATH}/qemu_bl1_setup.c ifeq (${ARM_ARCH_MAJOR},8) -BL1_SOURCES += lib/cpus/aarch64/aem_generic.S \ - lib/cpus/aarch64/cortex_a53.S \ - lib/cpus/aarch64/cortex_a57.S \ - lib/cpus/aarch64/cortex_a72.S \ - lib/cpus/aarch64/qemu_max.S \ +BL1_SOURCES += lib/cpus/${ARCH}/aem_generic.S \ + lib/cpus/${ARCH}/cortex_a53.S \ + lib/cpus/${ARCH}/cortex_a57.S \ + lib/cpus/${ARCH}/cortex_a72.S \ + lib/cpus/${ARCH}/qemu_max.S \ else BL1_SOURCES += lib/cpus/${ARCH}/cortex_a15.S diff --git a/plat/qemu/qemu_sbsa/platform.mk b/plat/qemu/qemu_sbsa/platform.mk index 5a6b1e11e812..05a66f81314f 100644 --- a/plat/qemu/qemu_sbsa/platform.mk +++ b/plat/qemu/qemu_sbsa/platform.mk @@ -30,7 +30,7 @@ PLAT_INCLUDES := -Iinclude/plat/arm/common/ \ -I${PLAT_QEMU_PATH}/include \ -Iinclude/common/tbbr -PLAT_INCLUDES += -Iinclude/plat/arm/common/${ARCH} +PLAT_INCLUDES += -Iinclude/plat/arm/common/aarch64 PLAT_BL_COMMON_SOURCES := ${PLAT_QEMU_COMMON_PATH}/qemu_common.c \ ${PLAT_QEMU_COMMON_PATH}/qemu_console.c \ -- 2.30.2

2 years, 10 months

2
1
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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. 2 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 382227: Error handling issues (CHECKED_RETURN) /plat/intel/soc/common/socfpga_sip_svc.c: 70 in intel_fpga_sdm_write_buffer() ________________________________________________________________________________________________________ *** CID 382227: Error handling issues (CHECKED_RETURN) /plat/intel/soc/common/socfpga_sip_svc.c: 70 in intel_fpga_sdm_write_buffer() 64 current_buffer %= FPGA_CONFIG_BUFFER_SIZE; 65 } else { 66 args[2] = bytes_per_block; 67 } 68 69 buffer->size_written += args[2]; >>> CID 382227: Error handling issues (CHECKED_RETURN) >>> Calling "mailbox_send_cmd_async" without checking return value (as is done elsewhere 9 out of 10 times). 70 mailbox_send_cmd_async(&send_id, MBOX_RECONFIG_DATA, args, 71 3U, CMD_INDIRECT); 72 73 buffer->subblocks_sent++; 74 max_blocks--; 75 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

2 years, 10 months

1
0
0 0

Trusted Services v1.0.0-beta release

by Gyorgy Szing

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

2 years, 10 months

1
0
0 0

Cancelled TF-A TechForum 1st December + update for 15th December

by Joanna Farley

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

2 years, 11 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Dec 15, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

2 years, 11 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Dec 1, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

2 years, 11 months

1
0
0 0

[PATCH] fix(console): fix crash on spin_unlock with cache disabled

by Baruch Siach

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

2 years, 11 months

2
1
0 0

Supporting QEMU in OpenCI

by Harrison Mutai

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/

2 years, 11 months

1
0
0 0

Re: 回复： building secure boot tf-a images without ROTK controlled by SW build engineer

by Neely, Brian

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?

2 years, 11 months

2
1
0 0

Trusted Firmware-A v2.8 Release Announcement

by Joanna Farley

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/

2 years, 11 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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…

2 years, 11 months

1
0
0 0

TF-A TechForum this week

by Joanna Farley

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

2 years, 11 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Nov 17, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

2 years, 11 months

1
0
0 0

Minimal kernel/firmware on Rock64 (rk3328)

by Robert Meissner

Hello, i found TF a very interesting project, however I would like to get booted with a really minimal firmware/kernel. I have a Rock64 with RK3328 Rockchip which I am trying to boot from sdcard with following sources: https://gitlab.com/jahro_me/sos/-/tree/master/ I have tried to setup UART for the device as described in the manual https://opensource.rock-chips.com/images/9/97/Rockchip_RK3328TRM_V1.1-Part1… On page 13 it states, the BOOT_ROM, INT_RAM is located at 0xffff0000. I have used this adress in kernel_entry https://gitlab.com/jahro_me/sos/-/blob/master/boot.s and in the main section https://gitlab.com/jahro_me/sos/-/blob/master/link.lds However, I could not get the kernel booted. I am not sure, if I need to remap the memory and how to do it. I guess, i should enable it with SGRF_SOC_CON2. Could anyone please help out to get the output, "Hello, You Rock!"? Best regards, Bob

2 years, 11 months

1
0
0 0

Submitting a patch to TF-A

by Jérôme Forissier

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

2 years, 11 months

4
8
0 0

Changelog for v2.8 Release

by Lauren Wehrmeister

Hi All, Please take a look at the changelog for your respective platforms ahead of the TF-A v2.8 release. The changelog is autogenerated from the commit messages of the patches that have been merged since the v2.7 release. Here's your chance to give us guidance on any small manual adjustments you would like to see. Patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17804/ Rendered Version: https://ci-builds.trustedfirmware.org/static-files/51m1_XLaarhS4BLLm1c3Mjdz… Thanks, Lauren

2 years, 11 months

1
0
0 0

Support for SVE + FP in TF-A

by Okash Khawaja

Hi, Currently TF-A doesn't support enabling both SVE and FP for both worlds. What can we do to support both SVE and FP in either world? Thanks, Okash

2 years, 11 months

2
2
0 0

PSCI OS-initiated mode

by Wing Li

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

2 years, 11 months

1
0
0 0

PSCI OS-initiated mode

by Wing Li

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

2 years, 11 months

1
0
0 0

Announcing TF-RMM v0.1.0

by Soby Mathew

Hi Everyone The TF-RMM team is pleased to announce the first public release of RMM implementation aligned to RMM Beta0 Specification [1] . The RMM is a software component that runs at Realm EL2 and forms part of a system which implements the Arm Confidential Compute Architecture (Arm CCA). The implementation can create Realm VMs in the Realm PAS and the Realm contents can be attested as specified in the RMM specification. The official trustedfirmware.org git repo can be found at : https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/. There is also a github read-only mirror and can be found at https://github.com/TF-RMM/tf-rmm . Contributions will be accepted via TF-RMM gerrit at trustedfirmware.org : https://review.trustedfirmware.org/q/project:TF-RMM%252Ftf-rmm Please see the readme [2] and the getting started guide [3] to get started with RMM. We expect patches for supporting Realm Management Extension (RME) in linux kernel and related kvm-unit-tests to be available in the coming months. The patch to exercise Realm creation and execution via TF-A-Tests is in review at the moment [4] and the OOB instructions for the same can be found in TF-A RME documentation [5]. We expect these patches to be part of the upcoming TF-A v2.8 release. The mailing list for the project is tf-rmm(a)lists.trustedfirmware.org<mailto:tf-rmm@lists.trustedfirmware.org>. Looking forward to fruitful community engagement and successful deployment Arm CCA systems in future. Best Regards Soby Mathew PS : We hope to setup readthedocs documentation in the coming days, but till then , please bear with the github rendering of the rst documentation. [1] https://developer.arm.com/documentation/den0137/1-0bet0/?lang=en [2] https://github.com/TF-RMM/tf-rmm/blob/main/docs/readme.rst [3] https://github.com/TF-RMM/tf-rmm/blob/main/docs/getting_started/getting-sta… [4] https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/17221 [5] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17610

2 years, 11 months

1
0
0 0

V2.8 Release code freeze notification

by Joanna Farley

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

2 years, 11 months

1
1
0 0

Conditional CMOs

by Okash Khawaja

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

2 years, 11 months

3
5
0 0

Canceled event with note: TF-A Tech Forum @ Thu Nov 3, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

2 years, 12 months

1
0
0 0

TF-A TechForum this Thursday 3rd November at 4pm GMT

by Joanna Farley

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

2 years, 12 months

1
1
0 0

Inconsistencies with PLAT_XLAT_TABLES_DYNAMIC

by Jeffrey Kardatzke

Hello, Is there a reason there are inconsistencies in the handling of PLAT_XLAT_TABLES_DYNAMIC? Specifically I'm referring to in some places it uses #ifdef logic: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/utils/… and then in others it's using #if: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/include/li… Also in some places it uses add_define: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/services/s… and in others it's explicitly adding the define (w/ or w/out a value) to the _FLAGS for an image. https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/imx/i… https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/b… I wanted to make use of this config option and noticed it wasn't getting picked up even when it was set and was considering cleaning up the usage of it by adding it to make_helpers/defaults.mk and then changing all the #ifdef's for it to be #if's. Thanks, -- Jeffrey Kardatzke jkardatzke(a)google.com Google, Inc.

2 years, 12 months

1
0
0 0

Re: 回复： building secure boot tf-a images without ROTK controlled by SW build engineer

by Neely, Brian

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

2 years, 12 months

1
0
0 0

Multi DTBs support in TF-A

by Ayoub Zaki

hello List, Is there anyway to support Multi DTBs in TF-A ? Mit freundlichen Grüßen / Kind regards -- Ayoub Zaki Embedded Systems Consultant

3 years

2
3
0 0

Making the first byte of the stack canary a NULL for better security

by zjw88282740＠gmail.com

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?

3 years

2
1
0 0

Debug RME feature on FVP_Base_RevC-2xAEMvA_11.19_14

by Ádám Tóth

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

3 years

2
2
0 0

回复： building secure boot tf-a images without ROTK controlled by SW build engineer

by Ben

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

3 years

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Oct 20, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

3 years

1
0
0 0

TF-A Tech Forum This Thursday

by Joanna Farley

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

3 years

1
1
0 0

building secure boot tf-a images without ROTK controlled by SW build engineer

by Xin.Xu＠analog.com

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

3 years

1
0
0 0

New TrustedFirwmare Maillist - TF-A LTS

by Don Harbin

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

3 years

1
0
0 0

Platform issues with mitigations of powerdown errata

by Boyan Karatotev

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

3 years

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Oct 6, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

3 years

2
1
0 0

security: BL2 at EL3 on v8a based system

by sandeep tripathy

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

3 years

2
4
1 0

Re: security: BL2 at EL3 on v8a based system

by Tripathy, 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

3 years

1
0
0 0

[PATCH TF-A] fix(plat/rcar3): Fix RPC-IF device node name

by Geert Uytterhoeven

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

3 years

3
7
1 0

Adding Openssl3 build capability to TF-A

by Gyorgy Szing

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.

3 years, 1 month

2
2
0 0

Finally, a TF-A LTS Proposal!

by Okash Khawaja

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

3 years, 1 month

5
7
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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…

3 years, 1 month

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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…

3 years, 1 month

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 4 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 4 of 4 defect(s) ** CID 380859: Integer handling issues (BAD_SHIFT) /drivers/arm/gic/v3/gic600_multichip.c: 290 in gic700_multichip_validate_data() ________________________________________________________________________________________________________ *** CID 380859: Integer handling issues (BAD_SHIFT) /drivers/arm/gic/v3/gic600_multichip.c: 290 in gic700_multichip_validate_data() 284 } 285 multichip_spi_blocks |= blocks_of_32; 286 } 287 288 /* ESPI IDs overlap check */ 289 if (spi_id_max > GIC700_ESPI_ID_MIN) { >>> CID 380859: Integer handling issues (BAD_SHIFT) >>> In expression "1 << (spi_id_max - 4096U + 1U >> 5)", left shifting by more than 31 bits has undefined behavior. The shift amount, "spi_id_max - 4096U + 1U >> 5", is as much as 32. 290 blocks_of_32 = BLOCKS_OF_32(spi_id_min - GIC700_ESPI_ID_MIN, 291 spi_id_max - GIC700_ESPI_ID_MIN); 292 if ((multichip_espi_blocks & blocks_of_32) != 0) { 293 ERROR("SPI IDs of Chip %u overlapping\n", i); 294 panic(); 295 } ** CID 380858: Control flow issues (DEADCODE) /drivers/nxp/crypto/caam/src/rng.c: 45 in is_hw_rng_instantiated() ________________________________________________________________________________________________________ *** CID 380858: Control flow issues (DEADCODE) /drivers/nxp/crypto/caam/src/rng.c: 45 in is_hw_rng_instantiated() 39 40 /*Check if either of the two state handles has been instantiated */ 41 if (rdsta & RNG_STATE0_HANDLE_INSTANTIATED) { 42 *state_handle = 0; 43 ret_code = 1; 44 } else if (rdsta & RNG_STATE0_HANDLE_INSTANTIATED) { >>> CID 380858: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "*state_handle = 1U;". 45 *state_handle = 1; 46 ret_code = 1; 47 } 48 49 return ret_code; 50 } ** CID 380857: Control flow issues (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 284 in stm32_fmc2_nand_setup_timing() ________________________________________________________________________________________________________ *** CID 380857: Control flow issues (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 284 in stm32_fmc2_nand_setup_timing() 278 if ((tset_mem < NAND_TADL_MIN) && 279 (thold_att < (NAND_TADL_MIN - tset_mem))) { 280 thold_att = NAND_TADL_MIN - tset_mem; 281 } 282 if ((tset_mem < NAND_TWH_MIN) && 283 (thold_att < (NAND_TWH_MIN - tset_mem))) { >>> CID 380857: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "thold_att = 30000UL - tset_...". 284 thold_att = NAND_TWH_MIN - tset_mem; 285 } 286 if ((tset_mem < NAND_TWHR_MIN) && 287 (thold_att < (NAND_TWHR_MIN - tset_mem))) { 288 thold_att = NAND_TWHR_MIN - tset_mem; 289 } ** CID 380856: Integer handling issues (BAD_SHIFT) /plat/intel/soc/common/drivers/qspi/cadence_qspi.c: 583 in cad_qspi_init() ________________________________________________________________________________________________________ *** CID 380856: Integer handling issues (BAD_SHIFT) /plat/intel/soc/common/drivers/qspi/cadence_qspi.c: 583 in cad_qspi_init() 577 578 cap_code = CAD_QSPI_STIG_RDID_CAPACITYID(rdid); 579 580 if (!(((cap_code >> 4) > 0x9) || ((cap_code & 0xf) > 0x9))) { 581 uint32_t decoded_cap = ((cap_code >> 4) * 10) + 582 (cap_code & 0xf); >>> CID 380856: Integer handling issues (BAD_SHIFT) >>> In expression "1 << decoded_cap + 6U", left shifting by more than 31 bits has undefined behavior. The shift amount, "decoded_cap + 6U", is as much as 105. 583 qspi_device_size = 1 << (decoded_cap + 6); 584 INFO("QSPI Capacity: %x\n\n", qspi_device_size); 585 586 } else { 587 ERROR("Invalid CapacityID encountered: 0x%02x\n", 588 cap_code); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 1 month

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Sep 22, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

3 years, 1 month

1
0
0 0

Issue with adding ssh key to review server

by sparlane＠gmail.com

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)

3 years, 1 month

2
2
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Sep 22, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

3 years, 2 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Sep 8, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

3 years, 2 months

1
0
0 0

How to trap aborts caused by TZASC?

by Chenxu Wang

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

3 years, 2 months

3
7
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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…

3 years, 2 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Aug 25, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

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

3 years, 2 months

1
0
0 0

Does FVP and current TF-A support the SVE/SVE2 programming?

by Chenxu Wang

Hi all, I want to perform some encryption/decryption in TF-A. I find that Arm provides some hardware-assisted instructions for encryption and integrity verification (e.g., AESE, SHA1...). But it seems that FVP does not support them. I recently read Armv9 and know that Arm purposes SVE/SVE2 to accelerate the matrix computation. It seems that it can be another approach to accelerate the encryption. Since I am a novice in Armv9 (and in FVP), thus, I want to ask: (1) Do FVP and TF-A support the SVE? If yes, how to configure it? (2) Do FVP and TF-A support the SVE2? If yes, how to configure it? Looking forward to your reply! Sincerely, WANG Chenxu

3 years, 2 months

2
2
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 380533: Null pointer dereferences (NULL_RETURNS) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 283 in spmc_shmem_obj_validate_id() ________________________________________________________________________________________________________ *** CID 380533: Null pointer dereferences (NULL_RETURNS) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 283 in spmc_shmem_obj_validate_id() 277 size_t emad_size; 278 struct ffa_emad_v1_0 *emad; 279 280 emad = spmc_shmem_obj_get_emad(desc, i, 281 MAKE_FFA_VERSION(1, 1), 282 &emad_size); >>> CID 380533: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "emad", which is known to be "NULL". 283 if (sp_id == emad->mapd.endpoint_id) { 284 found = true; 285 break; 286 } 287 } 288 return found; ** CID 380532: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 380532: Insecure data handling (TAINTED_SCALAR) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1754 in spmc_ffa_mem_relinquish() 1748 req->endpoint_array[0], sp_ctx->sp_id); 1749 ret = FFA_ERROR_INVALID_PARAMETER; 1750 goto err_unlock_all; 1751 } 1752 1753 /* Validate the caller is a valid participant. */ >>> CID 380532: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted expression "obj->desc.emad_count" to "spmc_shmem_obj_validate_id", which uses it as a loop boundary. 1754 if (!spmc_shmem_obj_validate_id(&obj->desc, sp_ctx->sp_id)) { 1755 WARN("%s: Invalid endpoint ID (0x%x).\n", 1756 __func__, req->endpoint_array[0]); 1757 ret = FFA_ERROR_INVALID_PARAMETER; 1758 goto err_unlock_all; 1759 } ** CID 380531: Integer handling issues (SIGN_EXTENSION) /bl32/tsp/tsp_ffa_main.c: 34 in send_ffa_pm_success() ________________________________________________________________________________________________________ *** CID 380531: Integer handling issues (SIGN_EXTENSION) /bl32/tsp/tsp_ffa_main.c: 34 in send_ffa_pm_success() 28 29 static ffa_endpoint_id16_t tsp_id, spmc_id; 30 31 static smc_args_t *send_ffa_pm_success(void) 32 { 33 return set_smc_args(FFA_MSG_SEND_DIRECT_RESP_SMC32, >>> CID 380531: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "tsp_id" with type "ffa_endpoint_id16_t" (16 bits, unsigned) is promoted in "(tsp_id << 16U) | spmc_id" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "(tsp_id << 16U) | spmc_id" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 34 tsp_id << FFA_DIRECT_MSG_SOURCE_SHIFT | 35 spmc_id, 36 FFA_FWK_MSG_BIT | 37 (FFA_PM_MSG_PM_RESP & FFA_FWK_MSG_MASK), 38 0, 0, 0, 0, 0); 39 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 2 months

1
0
0 0

TF-A RME support

by Shameerali Kolothum Thodi

Hi, I am trying to setup and run the RME support in TF-A, using the steps described here, https://trustedfirmware-a.readthedocs.io/en/latest/components/realm-managem… Build goes smoothly and when I launch FVP to run the RME tests using the command line mentioned in the link, the FVP terminal_0 seems to be get stuck at the below line, Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.7(debug):v2.7.0-235-g1631f9c75 NOTICE: BL1: Built : 11:44:37, Aug 22 2022 INFO: BL1: RAM 0x4035000 - 0x403c000 INFO: Loading image id=31 at address 0x4001010 INFO: Image id=31 loaded: 0x4001010 - 0x4001258 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 INFO: Loading image id=24 at address 0x4001300 INFO: Image id=24 loaded: 0x4001300 - 0x40015e4 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0x4022000 INFO: Image id=1 loaded: 0x4022000 - 0x402cca1 NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x4022000 INFO: SPSR = 0x3cd INFO: Configuring TrustZone Controller INFO: Total 6 regions set. Both the tf-a-tests.git and trusted-firmware-a.git are master branch and I am using the FVP_Base_RevC-2xAEMvA v11.18.16. I am totally new to this setup and maybe I am missing something here. Appreciate any help to get this resolved or tips to debug further. Thanks, Shameer

3 years, 2 months

3
6
0 0

TF-A CI often fail due to missing rebase

by Julius Werner

Hi Glen, Don, and others, I've seen that a couple of TF-A patches I've been CCed on recently often seem to fail the CI run (Allow-CI+1) due to some strange build-time errors that don't seem to have anything to do with the patch at hand, and then one of the maintainers usually suggests that the patch needs a rebase, and the next CI run succeeds after that. Here are two recent examples: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16160 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14666 I was wondering if this is a known problem and if the CI can do anything here to mitigate it and save developers from this extra layer of friction? I'm not really sure why a rebase was necessary in either of these examples or why the CI run failed before it (unless the whole repository was in a bad state that didn't build, but since all submissions are guarded by the CI that shouldn't have been possible?). But I also don't really understand why the rebase would make a difference for the CI anyway. Generally, when a patch is submitted in Gerrit, that means it is cherry-picked onto the current master (regardless of what parent commit it was uploaded with). Since the CI is supposed to be a test run for submission, I would expect that the CI should also test a patch by cherry-picking it onto the current master, not just by building the patch on top of whatever parent commit it was uploaded with. But since rebasing a patch evidently seems to make a difference to the CI, that suggests that it's currently doing the latter strategy? Should that maybe be changed to the former to avoid these kinds of issues? If this isn't a known problem yet maybe it would be worth adding it to the JIRA? Thanks, Julius

3 years, 2 months

4
6
0 0

A problem about TZASC in Armv9

by Chenxu Wang

Greetings, Armv9 introduces the RME and GPT technology. The GPT will separates the memory into unlimited regions with specific attributes. However, when I read the Armv9 manual and source code of TF-A, I still have some problems: 1. It seems that GPT is a feature on CPU, but not on a specific device (e.g.,TZC-400). Thus, will GPT conflict with TZC-400? I mean, when performing VA->PA on RAM, what is the detailed process if I enable both GPT and TZC-400? 2. I use the Arm FVP with Armv9 and RME extension enabled, and TF-A is "arm_cca" branch (with TF-A v2.5). Thus, in this version, what is the configuration for TZC-400 and GPT? Will it disable TZC-400 (I mean, GPT only) when booting Normal World? 3. Does GPT handle peripheral access (e.g., from DMA, GPU, Sensors... etc.)? I know TZC-400 will do it with NSAID. 4. Will GPT configures Read/Write/Execute features? All comments are valuable! SIncerely, WANG Chenxu

3 years, 2 months

3
7
0 0

Canceled event with note: TF-A Tech Forum @ Thu Aug 11, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with a note: "Cancelling this week. I have no topics ready for presenting also many folks are out on summer holidays. " TF-A Tech Forum Thursday Aug 11, 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

3 years, 2 months

1
0
0 0

TF-A TechForum 19th May Cancelled

by Bipin Ravi

All, This is to inform you all that the TF-A Techforum for Thursday, 19th May 2022 is cancelled as we didn't receive any topic for this week. The next meeting will now be Thursday, 2nd June 2022 at 16:00 - 17:00 BST. Thanks, Bipin Ravi

3 years, 3 months

1
1
0 0

Re: Question about disable MMU in BL1

by 邬金平

Hi, I have tried this before, there is a problem. on Armv8, when MMU disabled, the default attribute of memory is device, and device memory access has alignment requirements. For example, accessing address (0x1) will result in fault. Ben via TF-A <tf-a(a)lists.trustedfirmware.org> 于2022年7月19日周二 17:02写道： > Hello, > > To decrease feature in BL1, I plan to disable MMU in BL1 stage. > Are there any potential issues besides performance issues? > > BRs > > ------------------------------ > Ben(a)tsingmicro.com > -- > TF-A mailing list -- tf-a(a)lists.trustedfirmware.org > To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org >

3 years, 3 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 379362: Memory - illegal accesses (OVERRUN) /lib/psci/psci_common.c: 1046 in psci_is_last_on_cpu_safe() ________________________________________________________________________________________________________ *** CID 379362: Memory - illegal accesses (OVERRUN) /lib/psci/psci_common.c: 1046 in psci_is_last_on_cpu_safe() 1040 unsigned int i = 0; 1041 1042 /* 1043 * Traverse the forest of PSCI nodes, nodes with no parents 1044 * (invalid-nodes) are the root nodes. 1045 */ >>> CID 379362: Memory - illegal accesses (OVERRUN) >>> Overrunning array "psci_non_cpu_pd_nodes" of 5 16-byte elements at element index 5 (byte offset 95) using index "i" (which evaluates to 5). 1046 while ((psci_non_cpu_pd_nodes[i].parent_node == 1047 PSCI_PARENT_NODE_INVALID) && 1048 (i < PSCI_NUM_NON_CPU_PWR_DOMAINS)) { 1049 psci_get_parent_pwr_domain_nodes( 1050 psci_non_cpu_pd_nodes[i].cpu_start_idx, 1051 PLAT_MAX_PWR_LVL, parent_nodes); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 3 months

1
0
0 0

Question about disable MMU in BL1

by Ben

Hello, To decrease feature in BL1, I plan to disable MMU in BL1 stage. Are there any potential issues besides performance issues? BRs Ben(a)tsingmicro.com

3 years, 3 months

1
0
0 0

Question about maximum TF-A BL31 memory usage

by Peng Fan

Hi All, Is there any public BL31 memory usage data, such as static image size and runtime memory usage, with different feature enabled? For example, typical PSCI feature would require image size XXKB, runtime memory XXKB. enabling FFA would enlarge image size by XXKB, runtime memory enlarge XXKB. we are evaluating how much On-Chip RAM could be assigned for BL31, if there are any public data available, that would be great. Thanks, Peng.

3 years, 3 months

2
1
0 0

Rebooting LTS discussion

by Okash Khawaja

Hi, There have been discussions about having long term support releases for TF-A, e.g. the email thread [1] and a tech forum [2]. For partners releasing TF-A in their production devices, LTS is very much needed. From the previous discussions, it seems like there is an agreement that LTS is a good idea but we need to build consensus on how to support it. Any thoughts on this? Thanks, Okash [1] https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste… [2] https://www.trustedfirmware.org/docs/TF-A-LTS.pdf

3 years, 3 months

4
11
0 0

Question about FVP's dts

by Chenxu Wang

Hi all, I am using FVP base RevC. Recently I heard that this FVP supports a Mali G76 GPU, and I want to test it. To configure it, initially I add a node in linux/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dtsi, but it doesn't work. Finally, I find that I should configure trusted-firmware-a/fdts/fvp-base-gicv3-psci-1t.dts, and I can see a mali GPU node in /proc/device-tree. One of my booting command (sorry, the entire booting command is TOO long) is "--data cluster0.cpu0=arm-reference-platform/output/fvp/fvp-oe/uboot/fvp-base-aemv8a-aemv8a.dtb@0x82000000". And I use the following shell command to compile the TF-A: make PLAT=fvp all CROSS_COMPILE=aarch64-none-elf- ENABLE_RME=1 DEBUG=1 ARCH=aarch64 fip BL33=arm-reference-platform/output/fvp/components/fvp/uboot.bin FVP_HW_CONFIG_DTS=fdts/fvp-base-gicv3-psci-1t.dts ARM_DISABLE_TRUSTED_WDOG=1. So, I wonder, why the real DTS is in TF-A, instead of Linux? BTW, I wanna ask another question (although it is not proper to ask here, I cannot find FVP's mailing list): Can someone provide a proper dts configurations for FVP's Mali G76 GPU? Sincerely, WANG Chenxu

3 years, 3 months

2
1
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 4 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 379252: Concurrent data access violations (MISSING_LOCK) /plat/imx/imx8m/ddr/dram.c: 254 in dram_dvfs_handler() ________________________________________________________________________________________________________ *** CID 379252: Concurrent data access violations (MISSING_LOCK) /plat/imx/imx8m/ddr/dram.c: 254 in dram_dvfs_handler() 248 } else if (dram_info.dram_type == DDRC_DDR4) { 249 ddr4_swffc(&dram_info, fsp_index); 250 } 251 252 dram_info.current_fsp = fsp_index; 253 wait_ddrc_hwffc_done = false; >>> CID 379252: Concurrent data access violations (MISSING_LOCK) >>> Accessing "wfe_done" without holding lock "dfs_lock". Elsewhere, "wfe_done" is accessed with "dfs_lock" held 1 out of 2 times (1 of these accesses strongly imply that it is necessary). 254 wfe_done = 0; 255 dsb(); 256 sev(); 257 isb(); 258 } 259 260 SMC_RET1(handle, 0); ** CID 379251: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 379251: Memory - corruptions (OVERRUN) /plat/imx/imx8m/ddr/dram.c: 246 in dram_dvfs_handler() 240 } 241 242 /* flush the L1/L2 cache */ 243 dcsw_op_all(DCCSW); 244 245 if (dram_info.dram_type == DDRC_LPDDR4) { >>> CID 379251: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 3 by passing argument "fsp_index" (which evaluates to 3) in call to "lpddr4_swffc". 246 lpddr4_swffc(&dram_info, dev_fsp, fsp_index); 247 dev_fsp = (~dev_fsp) & 0x1; 248 } else if (dram_info.dram_type == DDRC_DDR4) { 249 ddr4_swffc(&dram_info, fsp_index); 250 } 251 ** CID 379250: (COPY_PASTE_ERROR) /plat/imx/imx8m/imx8mm/gpc.c: 182 in imx_gpc_pm_domain_enable() /plat/imx/imx8m/imx8mn/gpc.c: 81 in imx_gpc_pm_domain_enable() ________________________________________________________________________________________________________ *** CID 379250: (COPY_PASTE_ERROR) /plat/imx/imx8m/imx8mm/gpc.c: 182 in imx_gpc_pm_domain_enable() 176 /* HSIOMIX has no PU bit, so skip for it */ 177 if (domain_id != HSIOMIX) { 178 /* clear the PGC bit */ 179 mmio_clrbits_32(IMX_GPC_BASE + pwr_domain->pgc_offset, 0x1); 180 181 /* power up the domain */ >>> CID 379250: (COPY_PASTE_ERROR) >>> "mmio_setbits_32" in "mmio_setbits_32(809107704UL, pwr_domain->pwr_req)" looks like a copy-paste error. 182 mmio_setbits_32(IMX_GPC_BASE + PU_PGC_UP_TRG, pwr_domain->pwr_req); 183 184 /* wait for power request done */ 185 while (mmio_read_32(IMX_GPC_BASE + PU_PGC_UP_TRG) & pwr_domain->pwr_req) { 186 ; 187 } /plat/imx/imx8m/imx8mn/gpc.c: 81 in imx_gpc_pm_domain_enable() 75 /* HSIOMIX has no PU bit, so skip for it */ 76 if (domain_id != HSIOMIX) { 77 /* clear the PGC bit */ 78 mmio_clrbits_32(IMX_GPC_BASE + pwr_domain->pgc_offset, 0x1); 79 80 /* power up the domain */ >>> CID 379250: (COPY_PASTE_ERROR) >>> "mmio_setbits_32" in "mmio_setbits_32(809107704UL, pwr_domain->pwr_req)" looks like a copy-paste error. 81 mmio_setbits_32(IMX_GPC_BASE + PU_PGC_UP_TRG, pwr_domain->pwr_req); 82 83 /* wait for power request done */ 84 while (mmio_read_32(IMX_GPC_BASE + PU_PGC_UP_TRG) & pwr_domain->pwr_req) { 85 ; 86 } ** CID 379249: Memory - illegal accesses (OVERRUN) /plat/imx/imx8m/ddr/dram.c: 151 in dram_info_init() ________________________________________________________________________________________________________ *** CID 379249: Memory - illegal accesses (OVERRUN) /plat/imx/imx8m/ddr/dram.c: 151 in dram_info_init() 145 break; 146 } 147 } 148 dram_info.num_fsp = i; 149 150 /* check if has bypass mode support */ >>> CID 379249: Memory - illegal accesses (OVERRUN) >>> Overrunning array "dram_info.timing_info->fsp_table" of 4 4-byte elements at element index 4294967295 (byte offset 17179869183) using index "i - 1U" (which evaluates to 4294967295). 151 if (dram_info.timing_info->fsp_table[i-1] < 666) { 152 dram_info.bypass_mode = true; 153 } else { 154 dram_info.bypass_mode = false; 155 } 156 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 3 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Jul 14, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated with a note: "Updated Agenda for 14th July TF-A TechForum session next week." Changed: description TF-A Tech Forum Thursday Jul 14, 2022 ⋅ 4pm – 5pm United Kingdom Time AgendaLTS (Long Term Support) Releases DiscussionLed by Okash Khawaja (Google) and Varun Wadekar (NVIDIA)An initial discussion on some of the requirements and open questions of providing TF-A LTS releases. This initial session will concentrate on the technical aspects of LTS releases with suggestions and examples. Latter sessions can be expected to bring into the discussion resourcing and funding considerations.The hope is to establish and exchange views of the project community interest on this topic.==============================================================================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 thordur(a)google.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

3 years, 3 months

1
0
0 0

Re: Cannot successfully jump to the UEFI Boot Loader in the normal world with the RME enabled FVP_Base_RevC_2xAEMvA

by Erhu Feng

Hi, Thanks for the detailed documentation about how to enable RME in tf-a. I try to replace the tftf.bin with the normal boot firmware (edk2) to load the Linux in the normal world, but it fails. The log message from terminal_0 is shown below: INFO: RMM init start. INFO: RMM init end. INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x88000000 INFO: SPSR = 0x3c9 I found a possible solution from the archives: [https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…]. I try to modify the dts file under edk2-platform/Platform/ARM/VExpressPkg/DeviceTree/ to change the DDR memory range, which is similar to the modification for RME in [https://github.com/ARM-software/arm-trusted-firmware/blob/master/fdts/fvp-b…], but it does not solve the problem. So, how can I boot Linux in the normal world with RME enabled? Thanks,

3 years, 3 months

1
0
0 0

Manish Badarkhe added to maintainer list

by Manish Pandey2

Hi, I would like to introduce "Manish Badarkhe" <Manish.Badarkhe(a)arm.com> who has been added to the list of maintainers. This is based on his contribution to the project recently. Congratulations Manish B! Thanks Manish Pandey

3 years, 4 months

1
0
0 0

Addition of write() capability to IO MTD layer

by brian.neely＠analog.com

Hello, A project I’m working on requires write capability for a NOR flash device in BL2 (to update a small boot mux partition). I am considering adding this capability to the IO MTD layer (https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/io…), but before doing so wanted to confirm this is in line with the architecture of this subsystem. Can someone confirm if this is an acceptable change? Regards, Brian

3 years, 4 months

2
3
0 0

Version 1.2.12 of zlib was released

by mikemcternan＠google.com

Hi! It looks like TF-A contains zlib 1.2.11 e.g. https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/zlib/z… zlib.net gives their last release as 1.2.12 (March 27, 2022) with the following changelog: "Fix a deflate bug when using the Z_FIXED strategy that can result in out-of-bound accesses. Fix a deflate bug when the window is full in deflate_stored(). Speed up CRC-32 computations by a factor of 1.5 to 3. Use the hardware CRC-32 instruction on ARMv8 processors. Speed up crc32_combine() with powers of x tables. Add crc32_combine_gen() and crc32_combine_op() for fast combines. Due to the bug fixes, any installations of 1.2.11 should be replaced with 1.2.12." I'm not sure if this is significant as I couldn't find usages of deflate, but thought I would mention it in case others are relying on this functionality and wish to update. Kind regards, Mike

3 years, 4 months

2
1
0 0

synopsis emcc adma2/3 modes

by gauravverma999＠gmail.com

Hello all, I need to load Bl2 boot image file from emmc interface from 'Synopsys DesignWare Cores Mobile Storage Host Controller'. I can see an existing emmc driver for synopsis controller but it seems to have only support SDMA mode and not ADMA2 and ADMA3 modes. https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/sy… Is my understanding correct. Is there a specific reason why ADMA2/3 modes are not supported in existing driver. Any plan to update them soon? I can see adma2/3 mode support available in Linux driver though. https://github.com/torvalds/linux/blob/master/drivers/mmc/host/sdhci-of-dwc…

3 years, 4 months

1
0
0 0

Invitation with note: TF-A Tech Forum (additional) @ Thu Jun 23, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

You have been invited to the following event with this note: "An additional TF-A Techforum this week." Title: TF-A Tech Forum (additional) I'm creating an additional TF-A Techforum this week as we have a batch of topics coming up so this is an additional meeting to our normal bi weekly meetings. This session will. be recorded and made available on our TF0 Tech forum pagesThis week we would like to present on: Arm CCA RMM <-> EL3 interfacePresenter : Javier Almansa Sobrino Description: Covering the communication interface between RMM and EL3. This comprises of the Boot Interface and the RMM-EL3 runtime interface.Patches under review. This will also cover the RMM <> EL3 world switch register conventionRelated patch stack under review: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+… 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  Organizer: Trusted Firmware Public MeetingsTrusted Firmware Public Meetings When: Thu Jun 23, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * joanna.farley(a)arm.com - organizer * don.harbin(a)linaro.org * tf-a(a)lists.trustedfirmware.org * okash.khawaja(a)gmail.com * marek.bykowski(a)gmail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MnBubWJoYTBkYmRt… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 4 months

1
0
0 0

Re: Cannot successfully jump to the UEFI Boot Loader in the normal world with the RME enabled FVP_Base_RevC_2xAEMvA

by 冯二虎

Hi, Thanks for the detailed documentation about how to enable RME in tf-a. I try to replace the tftf.bin with the normal boot firmware (edk2) to load the Linux in the normal world, but it fails. The log message from terminal_0 is shown below: INFO: RMM init start. INFO: RMM init end. INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x88000000 INFO: SPSR = 0x3c9 I found a possible solution from the archives: [https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…]. I try to modify the dts file under edk2-platform/Platform/ARM/VExpressPkg/DeviceTree/ to change the DDR memory range, which is similar to the modification for RME in [https://github.com/ARM-software/arm-trusted-firmware/blob/master/fdts/fvp-b…], but it does not solve the problem. So, how can I boot Linux in the normal world with RME enabled? Thanks,

3 years, 4 months

2
1
0 0

Updated invitation: TF-A Tech Forum @ Thu Jun 30, 2022 4pm - 5:30pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: time, description TF-A Tech Forum Thursday Jun 30, 2022 ⋅ 4pm – 5:30pm United Kingdom Time Extending next week to 90 minutes as we will have two topics we hope to cover this week. More details nearer the time but the topics will cover the SPMC@EL3 recently released in v2.7 and some un related DRTM work to be released soon.Session will be recorded and shared as previous sessions.Joanna======================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

3 years, 4 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jun 16, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with a note: "Apologies. I have three topics being prepared but none of them are ready to present this week. If any of these are ready for next week I will try to run an additional session next week on 23rd June otherwise we will have something ready for 30th June. I believe on the ML there has been thread where there is the suggestion for another LTS discussion however those interested have not requested to host a new session on that topic. See https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… " TF-A Tech Forum Thursday Jun 16, 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

3 years, 4 months

1
0
0 0

Invitation: TF-A Tech Forum @ Thu Jun 16, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

TF-A Tech Forum Thursday Jun 16, 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 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

3 years, 4 months

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Jun 16, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled. TF-A Tech Forum Thursday Jun 16, 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

3 years, 4 months

1
0
0 0

Measured boot and external TPM modules

by Ramon Fried

Hi, I'm currently working on porting TFA to our upcoming SOC. We plan to support Measured boot using external I2C TPM module. I'm wondering about the implementation of that in BL1. Do you think that I need to write the measurements directly to the I2C module in BL1 ? I'm asking because I would like to have the least source of problems in BL1 which I can't upgrade. I thought of storing the measurements in secure RAM and perhaps copy later. Would love to hear your thoughts. PS. Actually I would love to have the option to choose to implement TPM also in SW (fTPM using optee - as was done in the POC). I think that if I store the measurement of BL2 in secure RAM I can later change the specific TPM while upgrading only BL2/BL31... Thanks, Ramon

3 years, 4 months

4
9
0 0

Trusted Firmware version 2.7 is now available

by Daniel Boulby

Hi TF-A Community, We are pleased to announce the formal release of Trusted Firmware-A version 2.7, Trusted Firmware-A Tests version 2.7 , Hafnium version 2.7 and TF-A OpenCI Scripts 2.7 Releases now involve the tagging of multiple sub repositories. These went live on 1st June 2022. Notable Features of the Version 2.7 Release across all repositories include: * Poseidon CPU Library * Branch Record Buffer Extension (FEAT_BRBE) for Non-secure World support (Armv9.2) * Statistical Profiling Extension (FEAT_SPEV1P2) support (Armv8.7) * WFE and WFI instructions with Timeout (FEAT_WFxT) support (Armv8.7) * Alternate Floating-Point (FEAT_AFP) support (Armv8.7) * Extended Cache Index (FEAT_CCIDX) support (Armv8.3) * Twenty-Five Errata Mitigations covering Cortex-A710, A510, A78, X2 * Spectre Branch History Buffer (BHB) mitigations * New Architectural Features Detection Mechanism (Experimental Feature) * System Memory Management Unit (SMMU) Granule Protection Checks (GPC) for Secure and Non-secure World transactions * Measured Boot Driver improvements * Threat Model Documentation updates * Hafnium Firmware Framework for Arm A-profile (FF-A) v1.1 continued support * Hafnium Memory Tagging Extension (MTE) stack tagging support * FF-A Secure Partition Manager (SPM) operating at EL3 added (Experimental Feature) * Eight (8) new platforms added * Thirty-Eight (38) platforms updated Please refer to the TF-A [1], Hafnium [2] and TF-A Tests [3] changelogs for the complete summary of changes the previous release. TF-A [4], TF-A Test [5], Hafnium [6] and TF-A OpenCI Scripts [7] repositories are available. [1] https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html#version-…<https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html#version-…> [2] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d…<https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d…> [3] Change Log & Release Notes — Trusted Firmware-A Tests documentation (trustedfirmware-a-tests.readthedocs.io)<https://trustedfirmware-a-tests.readthedocs.io/en/latest/change-log.html#> [4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.7 [5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.7 [6] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.7 [7] https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.7 <https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.7> Thanks, and best regards, Daniel Boulby

3 years, 5 months

1
0
0 0

[REGRESSION] v2.7-rc0 broken for STM32MP boards: lxa-mc1, avenger96, odyssey

by Ahmad Fatoum

Hello Yann, Hello Pascal, I've tried booting v2.7-rc0 on the lxa-mc1 and TF-A panics: NOTICE: CPU: STM32MP157C?? Rev.B NOTICE: Model: Linux Automation MC-1 board ERROR: regul ldo3: max value 750 is invalid PANIC at PC : 0x2ffeebb7 because the driver takes great offense at the content of the device tree. The parts in question were copy-pasted from ST DTs, but those ST DTs were fixed by commit 67d95409baae ("refactor(stm32mp1-fdts): update regulator description"). I can understand ST hesistancy to touch device trees of 'unofficial' boards, but I would appreciate that new features then, such as this regulator sanity checking, be made optional and off by default to not needlessly break other boards. Thanks, Ahmad -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

3 years, 5 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Jun 2, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with this note: "Public holiday in the UK so cancelling with week." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this 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   When: Thu Jun 2, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * 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 courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 5 months

1
0
0 0

Floating point math

by Bartus, Dan

We are using an arm ARCH-64 (A55) and we need to do some floating point math in BL2. It seems this is not enabled. Is there a reason why I cannot do FP math (security issue?) and if I can, how do I enable it? I am seeing this error when I use floats "-mgeneral-regs-only" thanks

3 years, 5 months

4
9
0 0

arm-trustedfirmware whether has unit test

by 郭浙伟(本记)

hi, I has quality engineer from china. I would to start study the Arm profile-A trustedfirmware and try to test it. I has read trustedfirmware documetion , From the Processes & policies Chap about CI part. "https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm… " Find ATF has Coverity Scan and test image build. but I would to know, trustedfirmware-a whether has unit test part in the code level quality check. Brs Tony

3 years, 5 months

2
1
0 0

ChangeLog-v2.7

by Jayanth Dodderi Chidanand

Hello All, Kindly take a look at the Changelog section (rendered version) for your respective platforms, as we approach closer to TF-A release v2.7. Please share your comments at review.trustedfirmware.org as we can address them accordingly. External Patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/15282 Rendered Version: https://ci-builds.trustedfirmware.org/static-files/La0ImPrSWDqkNWMSfH1vNhIR… Best regards, Jayanth

3 years, 5 months

2
1
0 0

Add neoverse-n1 support to QEMU SBSA

by Itaru Kitayama

Hi, I'd like to boot SBSA ref board with neoverse-n1 CPU, is anyone working on this? Itaru.

3 years, 5 months

2
8
1 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 10 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 10 of 10 defect(s) ** CID 378520: (OVERRUN) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 441 in spmc_shm_convert_shmem_obj_from_v1_0() /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 441 in spmc_shm_convert_shmem_obj_from_v1_0() ________________________________________________________________________________________________________ *** CID 378520: (OVERRUN) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 441 in spmc_shm_convert_shmem_obj_from_v1_0() 435 emad_array_in = mtd_orig->emad; 436 emad_array_out = (struct ffa_emad_v1_0 *) 437 ((uint8_t *) out + out->emad_offset); 438 439 /* Copy across the emad structs. */ 440 for (unsigned int i = 0U; i < out->emad_count; i++) { >>> CID 378520: (OVERRUN) >>> Overrunning array of 48 bytes at byte offset 48 by dereferencing pointer "&emad_array_out[i]". [Note: The source code implementation of the function has been overridden by a builtin model.] 441 memcpy(&emad_array_out[i], &emad_array_in[i], 442 sizeof(struct ffa_emad_v1_0)); 443 } 444 445 /* Place the mrd descriptors after the end of the emad descriptors.*/ 446 mrd_in_offset = emad_array_in->comp_mrd_offset; /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 441 in spmc_shm_convert_shmem_obj_from_v1_0() 435 emad_array_in = mtd_orig->emad; 436 emad_array_out = (struct ffa_emad_v1_0 *) 437 ((uint8_t *) out + out->emad_offset); 438 439 /* Copy across the emad structs. */ 440 for (unsigned int i = 0U; i < out->emad_count; i++) { >>> CID 378520: (OVERRUN) >>> Calling "memcpy" with "&emad_array_in[i]" and "16UL" is suspicious because "emad_array_in" points into a buffer of 16 bytes and the function call may access "(char *)&emad_array_in[i] + 15UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 441 memcpy(&emad_array_out[i], &emad_array_in[i], 442 sizeof(struct ffa_emad_v1_0)); 443 } 444 445 /* Place the mrd descriptors after the end of the emad descriptors.*/ 446 mrd_in_offset = emad_array_in->comp_mrd_offset; ** CID 378519: Memory - corruptions (OVERRUN) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 525 in spmc_shm_convert_mtd_to_v1_0() ________________________________________________________________________________________________________ *** CID 378519: Memory - corruptions (OVERRUN) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 525 in spmc_shm_convert_mtd_to_v1_0() 519 ((uint8_t *) mtd_orig + mtd_orig->emad_offset); 520 emad_array_out = out->emad; 521 522 /* Copy across the emad structs. */ 523 emad_in = emad_array_in; 524 for (unsigned int i = 0U; i < out->emad_count; i++) { >>> CID 378519: Memory - corruptions (OVERRUN) >>> Calling "memcpy" with "&emad_array_out[i]" and "16UL" is suspicious because "emad_array_out" points into a buffer of 16 bytes and the function call may access "(char *)&emad_array_out[i] + 15UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 525 memcpy(&emad_array_out[i], emad_in, 526 sizeof(struct ffa_emad_v1_0)); 527 528 emad_in += mtd_orig->emad_size; 529 } 530 ** CID 378518: Program hangs (ORDER_REVERSAL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1689 in spmc_ffa_mem_relinquish() ________________________________________________________________________________________________________ *** CID 378518: Program hangs (ORDER_REVERSAL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1689 in spmc_ffa_mem_relinquish() 1683 if (req->endpoint_count == 0) { 1684 WARN("%s: endpoint count cannot be 0.\n", __func__); 1685 ret = FFA_ERROR_INVALID_PARAMETER; 1686 goto err_unlock_mailbox; 1687 } 1688 >>> CID 378518: Program hangs (ORDER_REVERSAL) >>> Calling "spin_lock" acquires lock "spmc_shmem_obj_state.lock" while holding lock "mailbox.lock" (count: 2 / 5). 1689 spin_lock(&spmc_shmem_obj_state.lock); 1690 1691 obj = spmc_shmem_obj_lookup(&spmc_shmem_obj_state, req->handle); 1692 if (obj == NULL) { 1693 ret = FFA_ERROR_INVALID_PARAMETER; 1694 goto err_unlock_all; ** CID 378517: Program hangs (ORDER_REVERSAL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1338 in spmc_ffa_mem_retrieve_req() ________________________________________________________________________________________________________ *** CID 378517: Program hangs (ORDER_REVERSAL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1338 in spmc_ffa_mem_retrieve_req() 1332 WARN("%s: invalid length %u < %zu\n", __func__, total_length, 1333 min_desc_size); 1334 ret = FFA_ERROR_INVALID_PARAMETER; 1335 goto err_unlock_mailbox; 1336 } 1337 >>> CID 378517: Program hangs (ORDER_REVERSAL) >>> Calling "spin_lock" acquires lock "spmc_shmem_obj_state.lock" while holding lock "mailbox.lock" (count: 2 / 5). 1338 spin_lock(&spmc_shmem_obj_state.lock); 1339 1340 obj = spmc_shmem_obj_lookup(&spmc_shmem_obj_state, req->handle); 1341 if (obj == NULL) { 1342 ret = FFA_ERROR_INVALID_PARAMETER; 1343 goto err_unlock_all; ** CID 378516: Null pointer dereferences (REVERSE_INULL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1005 in spmc_ffa_fill_desc() ________________________________________________________________________________________________________ *** CID 378516: Null pointer dereferences (REVERSE_INULL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1005 in spmc_ffa_fill_desc() 999 } 1000 1001 /* Get a new obj to store the v1.1 descriptor. */ 1002 v1_1_obj = 1003 spmc_shmem_obj_alloc(&spmc_shmem_obj_state, v1_1_desc_size); 1004 >>> CID 378516: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "obj" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 1005 if (!obj) { 1006 ret = FFA_ERROR_NO_MEMORY; 1007 goto err_arg; 1008 } 1009 1010 /* Perform the conversion from v1.0 to v1.1. */ ** CID 378515: (TAINTED_SCALAR) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1446 in spmc_ffa_mem_retrieve_req() /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1407 in spmc_ffa_mem_retrieve_req() ________________________________________________________________________________________________________ *** CID 378515: (TAINTED_SCALAR) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1483 in spmc_ffa_mem_retrieve_req() 1477 1478 /* 1479 * If the caller is v1.0 convert the descriptor, otherwise copy 1480 * directly. 1481 */ 1482 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { >>> CID 378515: (TAINTED_SCALAR) >>> Passing tainted expression "obj->emad_count" to "spmc_populate_ffa_v1_0_descriptor", which uses it as a loop boundary. 1483 ret = spmc_populate_ffa_v1_0_descriptor(resp, obj, buf_size, 0, 1484 &copy_size, 1485 &out_desc_size); 1486 if (ret != 0U) { 1487 ERROR("%s: Failed to process descriptor.\n", __func__); 1488 goto err_unlock_all; /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1483 in spmc_ffa_mem_retrieve_req() 1477 1478 /* 1479 * If the caller is v1.0 convert the descriptor, otherwise copy 1480 * directly. 1481 */ 1482 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { >>> CID 378515: (TAINTED_SCALAR) >>> Passing tainted expression "obj->address_range_count" to "spmc_populate_ffa_v1_0_descriptor", which uses it as an offset. 1483 ret = spmc_populate_ffa_v1_0_descriptor(resp, obj, buf_size, 0, 1484 &copy_size, 1485 &out_desc_size); 1486 if (ret != 0U) { 1487 ERROR("%s: Failed to process descriptor.\n", __func__); 1488 goto err_unlock_all; /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1483 in spmc_ffa_mem_retrieve_req() 1477 1478 /* 1479 * If the caller is v1.0 convert the descriptor, otherwise copy 1480 * directly. 1481 */ 1482 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { >>> CID 378515: (TAINTED_SCALAR) >>> Passing tainted expression "obj->desc" to "spmc_populate_ffa_v1_0_descriptor", which uses it as an offset. 1483 ret = spmc_populate_ffa_v1_0_descriptor(resp, obj, buf_size, 0, 1484 &copy_size, 1485 &out_desc_size); 1486 if (ret != 0U) { 1487 ERROR("%s: Failed to process descriptor.\n", __func__); 1488 goto err_unlock_all; /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1483 in spmc_ffa_mem_retrieve_req() 1477 1478 /* 1479 * If the caller is v1.0 convert the descriptor, otherwise copy 1480 * directly. 1481 */ 1482 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { >>> CID 378515: (TAINTED_SCALAR) >>> Passing tainted expression "obj->emad_size" to "spmc_populate_ffa_v1_0_descriptor", which uses it as an offset. 1483 ret = spmc_populate_ffa_v1_0_descriptor(resp, obj, buf_size, 0, 1484 &copy_size, 1485 &out_desc_size); 1486 if (ret != 0U) { 1487 ERROR("%s: Failed to process descriptor.\n", __func__); 1488 goto err_unlock_all; /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1446 in spmc_ffa_mem_retrieve_req() 1440 &emad_size); 1441 if (emad == NULL) { 1442 ret = FFA_ERROR_INVALID_PARAMETER; 1443 goto err_unlock_all; 1444 } 1445 >>> CID 378515: (TAINTED_SCALAR) >>> Using tainted variable "obj->desc.emad_count" as a loop boundary. 1446 for (size_t j = 0; j < obj->desc.emad_count; j++) { 1447 other_emad = spmc_shmem_obj_get_emad( 1448 &obj->desc, j, MAKE_FFA_VERSION(1, 1), 1449 &emad_size); 1450 1451 if (other_emad == NULL) { /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1407 in spmc_ffa_mem_retrieve_req() 1401 ret = FFA_ERROR_INVALID_PARAMETER; 1402 goto err_unlock_all; 1403 } 1404 } 1405 1406 /* Validate that the provided emad offset and structure is valid.*/ >>> CID 378515: (TAINTED_SCALAR) >>> Using tainted variable "req->emad_count" as a loop boundary. 1407 for (size_t i = 0; i < req->emad_count; i++) { 1408 size_t emad_size; 1409 struct ffa_emad_v1_0 *emad; 1410 1411 emad = spmc_shmem_obj_get_emad(req, i, ffa_version, 1412 &emad_size); ** CID 378514: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 378514: (TAINTED_SCALAR) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1604 in spmc_ffa_mem_frag_rx() 1598 * If the caller is v1.0 convert the descriptor, otherwise copy 1599 * directly. 1600 */ 1601 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { 1602 size_t out_desc_size; 1603 >>> CID 378514: (TAINTED_SCALAR) >>> Passing tainted expression "obj->emad_count" to "spmc_populate_ffa_v1_0_descriptor", which uses it as a loop boundary. 1604 ret = spmc_populate_ffa_v1_0_descriptor(mbox->rx_buffer, obj, 1605 buf_size, 1606 fragment_offset, 1607 &copy_size, 1608 &out_desc_size); 1609 if (ret != 0U) { /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1604 in spmc_ffa_mem_frag_rx() 1598 * If the caller is v1.0 convert the descriptor, otherwise copy 1599 * directly. 1600 */ 1601 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { 1602 size_t out_desc_size; 1603 >>> CID 378514: (TAINTED_SCALAR) >>> Passing tainted expression "obj->emad_size" to "spmc_populate_ffa_v1_0_descriptor", which uses it as an offset. 1604 ret = spmc_populate_ffa_v1_0_descriptor(mbox->rx_buffer, obj, 1605 buf_size, 1606 fragment_offset, 1607 &copy_size, 1608 &out_desc_size); 1609 if (ret != 0U) { /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1604 in spmc_ffa_mem_frag_rx() 1598 * If the caller is v1.0 convert the descriptor, otherwise copy 1599 * directly. 1600 */ 1601 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { 1602 size_t out_desc_size; 1603 >>> CID 378514: (TAINTED_SCALAR) >>> Passing tainted expression "obj->address_range_count" to "spmc_populate_ffa_v1_0_descriptor", which uses it as an offset. 1604 ret = spmc_populate_ffa_v1_0_descriptor(mbox->rx_buffer, obj, 1605 buf_size, 1606 fragment_offset, 1607 &copy_size, 1608 &out_desc_size); 1609 if (ret != 0U) { /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1604 in spmc_ffa_mem_frag_rx() 1598 * If the caller is v1.0 convert the descriptor, otherwise copy 1599 * directly. 1600 */ 1601 if (ffa_version == MAKE_FFA_VERSION(1, 0)) { 1602 size_t out_desc_size; 1603 >>> CID 378514: (TAINTED_SCALAR) >>> Passing tainted expression "obj->desc" to "spmc_populate_ffa_v1_0_descriptor", which uses it as an offset. 1604 ret = spmc_populate_ffa_v1_0_descriptor(mbox->rx_buffer, obj, 1605 buf_size, 1606 fragment_offset, 1607 &copy_size, 1608 &out_desc_size); 1609 if (ret != 0U) { ** CID 378513: Null pointer dereferences (FORWARD_NULL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1320 in spmc_ffa_mem_retrieve_req() ________________________________________________________________________________________________________ *** CID 378513: Null pointer dereferences (FORWARD_NULL) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1320 in spmc_ffa_mem_retrieve_req() 1314 __func__); 1315 ret = FFA_ERROR_INVALID_PARAMETER; 1316 goto err_unlock_mailbox; 1317 } 1318 1319 if (req->emad_count == 0U) { >>> CID 378513: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "obj". 1320 WARN("%s: unsupported attribute desc count %u.\n", 1321 __func__, obj->desc.emad_count); 1322 return -EINVAL; 1323 } 1324 1325 /* Determine the appropriate minimum descriptor size. */ ** CID 378512: Null pointer dereferences (NULL_RETURNS) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1714 in spmc_ffa_mem_relinquish() ________________________________________________________________________________________________________ *** CID 378512: Null pointer dereferences (NULL_RETURNS) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 1714 in spmc_ffa_mem_relinquish() 1708 struct ffa_emad_v1_0 *emad; 1709 1710 for (unsigned int j = 0; j < obj->desc.emad_count; j++) { 1711 emad = spmc_shmem_obj_get_emad(&obj->desc, j, 1712 MAKE_FFA_VERSION(1, 1), 1713 &emad_size); >>> CID 378512: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "emad", which is known to be "NULL". 1714 if (req->endpoint_array[i] == 1715 emad->mapd.endpoint_id) { 1716 found = true; 1717 break; 1718 } 1719 } ** CID 378511: Memory - corruptions (OVERRUN) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 681 in spmc_shmem_check_obj() ________________________________________________________________________________________________________ *** CID 378511: Memory - corruptions (OVERRUN) /services/std_svc/spm/el3_spmc/spmc_shared_mem.c: 681 in spmc_shmem_check_obj() 675 } 676 677 /* 678 * Validate the calculated emad address resides within the 679 * descriptor. 680 */ >>> CID 378511: Memory - corruptions (OVERRUN) >>> "(uint8_t *)&obj->desc + obj->desc_size" evaluates to an address that is at byte offset 64 of an array of 48 bytes. 681 if ((uintptr_t) emad >= 682 (uintptr_t)((uint8_t *) &obj->desc + obj->desc_size)) { 683 WARN("Invalid emad access.\n"); 684 return -EINVAL; 685 } 686 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 5 months

1
0
0 0

[Question] fix(security): apply SMCCC_ARCH_WORKAROUND_3 to A73/A75/A72/A57

by JY Ho (何駿彥)

Dear Sirs, I’m TF-A developer of MediaTek and have a situation of CVE patch (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14298) with CA73. In CA73 platform with 64-bit TF-A v2.4 and 64-bit OP-TEE v3.16, system will occur halt during boot flow after we applied fix(security): apply SMCCC_ARCH_WORKAROUND_3 to A73/A75/A72/A57<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14298>. We used ICE to trace boot flow step by step, and found S-EL1 will ask EL3 its SMC_VERSION. In the fastcall, TF-A will execute wa_cve_2017_5715_bpiall_vbar()<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14298/11/lib…> which back up some setting and switch processor from AArch-64 to AArch-32 and does BPIALL<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14298/11/lib…>. But AArch32 cannot access and run over than 4G bus address without LPAE. (Suppose the TF-A and OP-TEE are locate on over than 4G bus address.) Maybe can we replace AArch32_stub with IC IALLU ? Or add LPAE setting before do AArch32_stub? (I don’t know it make sense or not) Thank you. JY

3 years, 5 months

3
3
1 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 6 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 3 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 6 of 6 defect(s) ** CID 378487: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 378487: Integer handling issues (INCOMPATIBLE_CAST) /plat/intel/soc/common/socfpga_sip_svc.c: 738 in sip_smc_handler_v1() 732 733 case INTEL_SIP_SMC_RSU_NOTIFY: 734 status = intel_rsu_notify(x1); 735 SMC_RET1(handle, status); 736 737 case INTEL_SIP_SMC_RSU_RETRY_COUNTER: >>> CID 378487: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "rsu_respbuf" points to an object whose effective type is "unsigned long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 738 status = intel_rsu_retry_counter((uint32_t *)rsu_respbuf, 739 ARRAY_SIZE(rsu_respbuf), &retval); 740 if (status) { 741 SMC_RET1(handle, status); 742 } else { 743 SMC_RET2(handle, status, retval); ** CID 378486: Control flow issues (NO_EFFECT) /plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1734 in intel_fcs_aes_crypt_update_finalize() ________________________________________________________________________________________________________ *** CID 378486: Control flow issues (NO_EFFECT) /plat/intel/soc/common/sip/socfpga_sip_fcs.c: 1734 in intel_fcs_aes_crypt_update_finalize() 1728 1729 if (is_finalised != 0U) { 1730 memset((void *)&fcs_aes_init_payload, 0, 1731 sizeof(fcs_aes_init_payload)); 1732 } 1733 >>> CID 378486: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "status < 0U". 1734 if (status < 0U) { 1735 return INTEL_SIP_SMC_STATUS_ERROR; 1736 } 1737 1738 return INTEL_SIP_SMC_STATUS_OK; ** CID 378485: Null pointer dereferences (FORWARD_NULL) /lib/psa/measured_boot.c: 26 in print_byte_array() ________________________________________________________________________________________________________ *** CID 378485: Null pointer dereferences (FORWARD_NULL) /lib/psa/measured_boot.c: 26 in print_byte_array() 20 21 if (array == NULL || len == 0U) { 22 (void)printf("\n"); 23 } 24 25 for (i = 0U; i < len; ++i) { >>> CID 378485: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "array". 26 (void)printf(" %02x", array[i]); 27 if ((i & U(0xF)) == U(0xF)) { 28 (void)printf("\n"); 29 if (i < (len - 1U)) { 30 INFO("\t\t:"); 31 } ** CID 378484: Null pointer dereferences (FORWARD_NULL) /plat/intel/soc/common/soc/socfpga_mailbox.c: 244 in mailbox_read_response_async() ________________________________________________________________________________________________________ *** CID 378484: Null pointer dereferences (FORWARD_NULL) /plat/intel/soc/common/soc/socfpga_mailbox.c: 244 in mailbox_read_response_async() 238 ret_resp_len = MBOX_RESP_LEN(mailbox_resp_ctr.payload->header); 239 if ((ret_resp_len > 0) && (response == NULL) && resp_len) { 240 if (*resp_len > ret_resp_len) { 241 *resp_len = ret_resp_len; 242 } 243 >>> CID 378484: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "response" to "memcpy", which dereferences it. [Note: The source code implementation of the function has been overridden by a builtin model.] 244 memcpy((uint8_t *) response, 245 (uint8_t *) mailbox_resp_ctr.payload->data, 246 *resp_len * MBOX_WORD_BYTE); 247 } 248 249 /* reset async response param */ ** CID 378483: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 378483: Integer handling issues (INCOMPATIBLE_CAST) /plat/intel/soc/common/socfpga_sip_svc.c: 881 in sip_smc_handler_v1() 875 case INTEL_SIP_SMC_FCS_ATTESTATION_MEASUREMENTS: 876 status = intel_fcs_get_measurement(x1, x2, x3, 877 (uint32_t *) &x4, &mbox_error); 878 SMC_RET4(handle, status, mbox_error, x3, x4); 879 880 case INTEL_SIP_SMC_FCS_GET_ATTESTATION_CERT: >>> CID 378483: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&x3" points to an object whose effective type is "unsigned long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 881 status = intel_fcs_get_attestation_cert(x1, x2, 882 (uint32_t *) &x3, &mbox_error); 883 SMC_RET4(handle, status, mbox_error, x2, x3); 884 885 case INTEL_SIP_SMC_FCS_CREATE_CERT_ON_RELOAD: 886 status = intel_fcs_create_cert_on_reload(x1, &mbox_error); ** CID 378482: (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 378482: (INCOMPATIBLE_CAST) /plat/intel/soc/common/socfpga_sip_svc.c: 871 in sip_smc_handler_v1() 865 866 case INTEL_SIP_SMC_FCS_CHIP_ID: 867 status = intel_fcs_chip_id(&retval, &retval2, &mbox_error); 868 SMC_RET4(handle, status, mbox_error, retval, retval2); 869 870 case INTEL_SIP_SMC_FCS_ATTESTATION_SUBKEY: >>> CID 378482: (INCOMPATIBLE_CAST) >>> Pointer "&x4" points to an object whose effective type is "unsigned long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 871 status = intel_fcs_attestation_subkey(x1, x2, x3, 872 (uint32_t *) &x4, &mbox_error); 873 SMC_RET4(handle, status, mbox_error, x3, x4); 874 875 case INTEL_SIP_SMC_FCS_ATTESTATION_MEASUREMENTS: 876 status = intel_fcs_get_measurement(x1, x2, x3, /plat/intel/soc/common/socfpga_sip_svc.c: 876 in sip_smc_handler_v1() 870 case INTEL_SIP_SMC_FCS_ATTESTATION_SUBKEY: 871 status = intel_fcs_attestation_subkey(x1, x2, x3, 872 (uint32_t *) &x4, &mbox_error); 873 SMC_RET4(handle, status, mbox_error, x3, x4); 874 875 case INTEL_SIP_SMC_FCS_ATTESTATION_MEASUREMENTS: >>> CID 378482: (INCOMPATIBLE_CAST) >>> Pointer "&x4" points to an object whose effective type is "unsigned long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 876 status = intel_fcs_get_measurement(x1, x2, x3, 877 (uint32_t *) &x4, &mbox_error); 878 SMC_RET4(handle, status, mbox_error, x3, x4); 879 880 case INTEL_SIP_SMC_FCS_GET_ATTESTATION_CERT: 881 status = intel_fcs_get_attestation_cert(x1, x2, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 5 months

1
0
0 0

imx8mn and HAB

by Heiko Thiery

Hi, We use mainline TF-A and have problems using the HAB API in the U-Boot. We see for example that the hab_auth_img command fails in the mainline U-Boot. If we switch to the downstream NXP TF-A it works. Is this to be expected? -- Heiko

3 years, 5 months

3
5
0 0

Issue about passing arguments between the BL1 and BL2 in Arch32

by 邬金平

Hi Arguments between the BL1 and BL2 is overlap by zeromem when BL2 start. 1. BL2 save r3 to r12 arm-trusted-firmware/bl2/aarch32/bl2_entrypoint.S /*--------------------------------------------- * Save arguments x0 - x3 from BL1 for future * use. * --------------------------------------------- */ mov r9, r0 mov r10, r1 mov r11, r2 mov r12, r3 2. BL2 call zeromem to clear bss arm-trusted-firmware/bl2/aarch32/bl2_entrypoint.S ldr r0, =__BSS_START__ ldr r1, =__BSS_END__ sub r1, r1, r0 bl zeromem arm-trusted-firmware/lib/aarch32/misc_helpers.S tmp .req r12 /* Temporary scratch register */ r12 used as scratch register 3. r3 restore from r12 arm-trusted-firmware/bl2/aarch32/bl2_entrypoint.S mov r0, r9 mov r1, r10 mov r2, r11 mov r3, r12 I can try to save it in other registers, but can not guarantee that the register will not be damaged. Is there any better way to deal with this problem? Thanks.

3 years, 5 months

2
1
0 0

ECLAIR for static analysis

by Varun Wadekar

Hi @Joanna<mailto:Joanna.Farley@arm.com>, I am glad that tf.org has taken this step to improve code quality with the latest announcement [1]. Some questions to understand the model a bit better. 1. Is the tool available to the community? 2. Can people run this before submission? Or is it restricted to a certain group? 3. Will full reports be released to the community? 4. What will the deployment model look like? I suggest we discuss this in a tech forum to reach the entire community. -Varun [1] https://www.trustedfirmware.org/news/BugSeng_press_release/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.trust…> https://www.bugseng.com/eclair<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bugse…> https://www.bugseng.com/sites/default/files/resources/ECLAIR_TUV-SUD_Certif…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bugse…>

3 years, 5 months

2
1
0 0

About SVE issue

by Ming Huang

Hi, We use TF-A v2.5 with ENABLE_SVE_FOR_NS=1 and SPM_MM=1 and boot linux kernel is ok. Atfer upgrade TF-A with patch fix(spm_mm): do not compile if SVE/SME is enabled (4333f95bedb), we set ENABLE_SVE_FOR_NS=0 to fix compile error, but we get exception and hang in EL3 when boot kernel: ----------------------------------------------------------------------------------- [ 0.000000] Linux version 5.10.23-003debug.ali5000.alios7.aarch64 (root(a)j66e01291.sqa.eu95) (gcc (GCC) 10.2.1 20200825 (Alibaba 10.2.1-3 2.17) ...... [ 0.000000] pcpu-alloc: [1] 80 [1] 81 [1] 82 [1] 83 [1] 84 [1] 85 [1] 86 [1] 87 [ 0.000000] pcpu-alloc: [1] 88 [1] 89 [1] 90 [1] 91 [1] 92 [1] 93 [1] 94 [1] 95 ERROR: Excepton received on 0x81000000, spsr_el3:89,reason:1 esr_el3:0x66000000 Exception Class = 19: Access to SVE functionality trapped as a result of CPACR_EL1.ZEN,CPTR_EL2.ZEN, CPTR_EL2.TZ, or CPTR_EL3.EZ. ----------------------------------------------------------------------------------- How to fix the exception issue? Can we remove the below lines? ifeq (${ENABLE_SVE_FOR_NS},1) $(error "Error: SPM_MM is not compatible with ENABLE_SVE_FOR_NS") endif Regards, Ming Huang

3 years, 5 months

2
2
0 0

Trusted Firmware-A v2.7 release activities in May

by Daniel Boulby

TF-A Community, This is to notify that we are planning to target the Trusted Firmware-A 2.7 release during the 4th week of May as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.6 release. As part of this, a release candidate tag will be created and release activities will commence from 23rd May across all TF-A repositories. Essentially, we will not merge any major enhancements from this date until the release is made. Please ensure any patches desired to make the 2.7 release are submitted in good time to be complete by 20th May. Any major enhancement patches still open after that date will not be merged until after the release. This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Jobs. We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start. Thanks, Daniel

3 years, 5 months

1
0
0 0

Issue in HW config consumption by secure BL components

by Manish Badarkhe

Hi All, Currently, in Arm platforms, BL2 loads HW config in the non-secure memory so that it can be consumed by both non-secure components (BL33) and secure (BL31, BL32) components. In most cases, this shouldn't be an issue since no software runs in non-secure world at this time (i.e. non-secure world has not been started yet) However, it doesn't provide a guarantee though since any malicious external NS-agents (such as an external debugger)can take control of this memory region for update/corruption after BL2 loads this region and before BL31 consumes it. Consider below scenario: 1. BL2 loads HW_CONFIG from flash to NS DRAM. 2. BL2 authenticates HW_CONFIG in NS DRAM. 3. A malicious non-secure agent modifies the contents of HW_CONFIG in NS DRAM, such that it induces a different behaviour in BL31. 1. BL31 consumes HW_CONFIG without noticing it has changed. To overcome this issue, I created a patch [1] to load the HW-config into secure memory, and that eventually will be used by BL31/sp_min and BL32 components. Additionally, BL31/sp_min copies the HW-config present in secure memory to a non-secure location before passing it on to BL33. In order to accomplish this, mapped secure DRAM in BL31/sp_min and BL32, and non-secure DRAM in BL31/sp_min. I believe some platforms may have similar kind of issue i.e. HW config placed in non-secure memory consumed by both secure and non-secure components. It is appreciated if you review the patch [1] I posted and provide feedback. This patch [1] also mitigates threat ID #3 for FVP platform as per the TF-A threat model [2] (Bypass image authentication scenario). [1]: https://review.trustedfirmware.org/q/topic:%22refactor-hw-config-load%22+(s… [2]: https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_mode… Thanks, Manish Badarkhe

3 years, 5 months

1
1
0 0

TF-A Tech-Forum Agenda for Thursday 05-May-22 at 4pm BST

by Bipin Ravi

Topic: FF-A v1.1 Boot protocol implementation Presented by: Joao Alves Agenda: This session presents the recently introduced FF-A v1.1 Boot protocol implementation, motivations and challenges. The change set spans across TF-A, Hafnium and TF-A-tests repositories. The presentation covers the TF-A build flow and Secure Partitions packaging, how Hafnium consumes the new SP package format and passes boot data to SPs. Link to changes: FF-A v1.1 boot protocol<https://review.trustedfirmware.org/q/topic:%22ja%252Fboot_protocol%22+(stat…> ================================================= We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/https://www.g… Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974https://www.google.com/url?q=https://zoom.us/j/… Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7hhttps://www.google.com/url?q=https://zoom.us/u/… Thanks & best regards, --Bipin Ravi

3 years, 6 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 378361: Null pointer dereferences (NULL_RETURNS) /plat/arm/board/fvp/fvp_bl2_setup.c: 84 in plat_get_next_bl_params() ________________________________________________________________________________________________________ *** CID 378361: Null pointer dereferences (NULL_RETURNS) /plat/arm/board/fvp/fvp_bl2_setup.c: 84 in plat_get_next_bl_params() 78 79 /* To retrieve actual size of the HW_CONFIG */ 80 param_node = get_bl_mem_params_node(HW_CONFIG_ID); 81 assert(param_node != NULL); 82 83 /* Copy HW config from Secure address to NS address */ >>> CID 378361: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "hw_config_info", which is known to be "NULL". 84 memcpy((void *)hw_config_info->ns_config_addr, 85 (void *)hw_config_info->config_addr, 86 (size_t)param_node->image_info.image_size); 87 88 /* 89 * Ensure HW-config device tree committed to memory, as there is ** CID 378360: (NULL_RETURNS) /plat/renesas/rzg/bl2_plat_setup.c: 411 in bl2_plat_handle_post_image_load() /plat/renesas/rcar/bl2_plat_setup.c: 446 in bl2_plat_handle_post_image_load() /plat/st/stm32mp1/bl2_plat_setup.c: 466 in bl2_plat_handle_post_image_load() /plat/renesas/rcar/bl2_plat_setup.c: 465 in bl2_plat_handle_post_image_load() /plat/renesas/rzg/bl2_plat_setup.c: 407 in bl2_plat_handle_post_image_load() /plat/st/stm32mp1/bl2_plat_setup.c: 472 in bl2_plat_handle_post_image_load() /plat/renesas/rcar/bl2_plat_setup.c: 448 in bl2_plat_handle_post_image_load() /plat/renesas/rcar/bl2_plat_setup.c: 440 in bl2_plat_handle_post_image_load() /plat/renesas/rzg/bl2_plat_setup.c: 397 in bl2_plat_handle_post_image_load() /plat/renesas/rzg/bl2_plat_setup.c: 404 in bl2_plat_handle_post_image_load() /plat/st/stm32mp1/bl2_plat_setup.c: 529 in bl2_plat_handle_post_image_load() ________________________________________________________________________________________________________ *** CID 378360: (NULL_RETURNS) /plat/renesas/rzg/bl2_plat_setup.c: 411 in bl2_plat_handle_post_image_load() 405 } 406 407 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 408 sizeof(entry_point_info_t)); 409 break; 410 case BL33_IMAGE_ID: >>> CID 378360: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "&bl_mem_params->ep_info" when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 411 memcpy(&params->bl33_ep_info, &bl_mem_params->ep_info, 412 sizeof(entry_point_info_t)); 413 break; 414 default: 415 break; 416 } /plat/renesas/rcar/bl2_plat_setup.c: 446 in bl2_plat_handle_post_image_load() 440 bl_mem_params->image_info.image_base = dest; 441 break; 442 case BL32_IMAGE_ID: 443 ret = rcar_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 444 &dest); 445 if (!ret) >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 446 bl_mem_params->image_info.image_base = dest; 447 448 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 449 sizeof(entry_point_info_t)); 450 break; 451 case BL33_IMAGE_ID: /plat/st/stm32mp1/bl2_plat_setup.c: 466 in bl2_plat_handle_post_image_load() 460 switch (image_ids[i]) { 461 case BL32_IMAGE_ID: 462 bl_mem_params->ep_info.pc = config_info->config_addr; 463 464 /* In case of OPTEE, initialize address space with tos_fw addr */ 465 pager_mem_params = get_bl_mem_params_node(BL32_EXTRA1_IMAGE_ID); >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "pager_mem_params", which is known to be "NULL". 466 pager_mem_params->image_info.image_base = config_info->config_addr; 467 pager_mem_params->image_info.image_max_size = 468 config_info->config_max_size; 469 470 /* Init base and size for pager if exist */ 471 paged_mem_params = get_bl_mem_params_node(BL32_EXTRA2_IMAGE_ID); /plat/renesas/rcar/bl2_plat_setup.c: 465 in bl2_plat_handle_post_image_load() 459 } else { 460 /* plain image, copy it in place */ 461 memcpy((void *)BL33_BASE, (void *)BL33_COMP_BASE, 462 bl_mem_params->image_info.image_size); 463 } 464 #endif >>> CID 378360: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "&bl_mem_params->ep_info" when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 465 memcpy(&params->bl33_ep_info, &bl_mem_params->ep_info, 466 sizeof(entry_point_info_t)); 467 break; 468 } 469 470 return 0; /plat/renesas/rzg/bl2_plat_setup.c: 407 in bl2_plat_handle_post_image_load() 401 ret = rzg_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 402 &dest); 403 if (ret == 0U) { 404 bl_mem_params->image_info.image_base = dest; 405 } 406 >>> CID 378360: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "&bl_mem_params->ep_info" when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 407 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 408 sizeof(entry_point_info_t)); 409 break; 410 case BL33_IMAGE_ID: 411 memcpy(&params->bl33_ep_info, &bl_mem_params->ep_info, 412 sizeof(entry_point_info_t)); /plat/st/stm32mp1/bl2_plat_setup.c: 472 in bl2_plat_handle_post_image_load() 466 pager_mem_params->image_info.image_base = config_info->config_addr; 467 pager_mem_params->image_info.image_max_size = 468 config_info->config_max_size; 469 470 /* Init base and size for pager if exist */ 471 paged_mem_params = get_bl_mem_params_node(BL32_EXTRA2_IMAGE_ID); >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "paged_mem_params", which is known to be "NULL". 472 paged_mem_params->image_info.image_base = STM32MP_DDR_BASE + 473 (dt_get_ddr_size() - STM32MP_DDR_S_SIZE - 474 STM32MP_DDR_SHMEM_SIZE); 475 paged_mem_params->image_info.image_max_size = STM32MP_DDR_S_SIZE; 476 break; 477 /plat/renesas/rcar/bl2_plat_setup.c: 448 in bl2_plat_handle_post_image_load() 442 case BL32_IMAGE_ID: 443 ret = rcar_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 444 &dest); 445 if (!ret) 446 bl_mem_params->image_info.image_base = dest; 447 >>> CID 378360: (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "&bl_mem_params->ep_info" when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 448 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 449 sizeof(entry_point_info_t)); 450 break; 451 case BL33_IMAGE_ID: 452 #if RCAR_GEN3_BL33_GZIP == 1 453 if ((mmio_read_32(BL33_COMP_BASE) & 0xffff) == 0x8b1f) { /plat/renesas/rcar/bl2_plat_setup.c: 440 in bl2_plat_handle_post_image_load() 434 435 switch (image_id) { 436 case BL31_IMAGE_ID: 437 ret = rcar_get_dest_addr_from_cert(SOC_FW_CONTENT_CERT_ID, 438 &dest); 439 if (!ret) >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 440 bl_mem_params->image_info.image_base = dest; 441 break; 442 case BL32_IMAGE_ID: 443 ret = rcar_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 444 &dest); 445 if (!ret) /plat/renesas/rzg/bl2_plat_setup.c: 397 in bl2_plat_handle_post_image_load() 391 392 switch (image_id) { 393 case BL31_IMAGE_ID: 394 ret = rzg_get_dest_addr_from_cert(SOC_FW_CONTENT_CERT_ID, 395 &dest); 396 if (ret == 0U) { >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 397 bl_mem_params->image_info.image_base = dest; 398 } 399 break; 400 case BL32_IMAGE_ID: 401 ret = rzg_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 402 &dest); /plat/renesas/rzg/bl2_plat_setup.c: 404 in bl2_plat_handle_post_image_load() 398 } 399 break; 400 case BL32_IMAGE_ID: 401 ret = rzg_get_dest_addr_from_cert(TRUSTED_OS_FW_CONTENT_CERT_ID, 402 &dest); 403 if (ret == 0U) { >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 404 bl_mem_params->image_info.image_base = dest; 405 } 406 407 memcpy(&params->bl32_ep_info, &bl_mem_params->ep_info, 408 sizeof(entry_point_info_t)); 409 break; /plat/st/stm32mp1/bl2_plat_setup.c: 529 in bl2_plat_handle_post_image_load() 523 bl_mem_params->ep_info.args.arg1 = 0; /* Unused */ 524 bl_mem_params->ep_info.args.arg2 = 0; /* No DT supported */ 525 } else { 526 #if !STM32MP_USE_STM32IMAGE 527 bl_mem_params->ep_info.pc = bl_mem_params->image_info.image_base; 528 tos_fw_mem_params = get_bl_mem_params_node(TOS_FW_CONFIG_ID); >>> CID 378360: (NULL_RETURNS) >>> Dereferencing "tos_fw_mem_params", which is known to be "NULL". 529 bl_mem_params->image_info.image_max_size += 530 tos_fw_mem_params->image_info.image_max_size; 531 #endif /* !STM32MP_USE_STM32IMAGE */ 532 bl_mem_params->ep_info.args.arg0 = 0; 533 } 534 break; ** CID 378359: Null pointer dereferences (NULL_RETURNS) /plat/st/common/bl2_io_storage.c: 413 in bl2_plat_handle_pre_image_load() ________________________________________________________________________________________________________ *** CID 378359: Null pointer dereferences (NULL_RETURNS) /plat/st/common/bl2_io_storage.c: 413 in bl2_plat_handle_pre_image_load() 407 image_block_spec.length = entry->length; 408 #endif 409 gpt_init_done = true; 410 } else { 411 bl_mem_params_node_t *bl_mem_params = get_bl_mem_params_node(image_id); 412 >>> CID 378359: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "bl_mem_params", which is known to be "NULL". 413 mmc_block_dev_spec.buffer.offset = bl_mem_params->image_info.image_base; 414 mmc_block_dev_spec.buffer.length = bl_mem_params->image_info.image_max_size; 415 } 416 417 break; 418 #endif ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 6 months

1
0
0 0

Trusted Firmware-A v2.7 release activities in May 2022

by Joanna Farley

TF-A Community, This is to notify that we are planning to target the Trusted Firmware-A 2.7 release during the fourth week of May 2021 as part of the regular 6 month cadence. This is a little later than originally targeted due to the number of patches still under review from contributors. The aim is to consolidate all TF-A work since the 2.6 release. As part of this, a release candidate tag will be created and release activities will commence some time during the week ending 20th May 2022 across all TF-A repositories. Any major enhancement patches still open after that date will not be merged until after the release. This release will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Jobs. We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start. Thanks Joanna

3 years, 6 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 378231: Control flow issues (UNREACHABLE) /plat/intel/soc/common/socfpga_sip_svc.c: 312 in is_out_of_sec_range() ________________________________________________________________________________________________________ *** CID 378231: Control flow issues (UNREACHABLE) /plat/intel/soc/common/socfpga_sip_svc.c: 312 in is_out_of_sec_range() 306 static int is_out_of_sec_range(uint64_t reg_addr) 307 { 308 #if DEBUG 309 return 0; 310 #endif 311 >>> CID 378231: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "switch (reg_addr) { case ...". 312 switch (reg_addr) { 313 case(0xF8011100): /* ECCCTRL1 */ 314 case(0xF8011104): /* ECCCTRL2 */ 315 case(0xF8011110): /* ERRINTEN */ 316 case(0xF8011114): /* ERRINTENS */ 317 case(0xF8011118): /* ERRINTENR */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 6 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Apr 21, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Topic: Feature Detection MechanismPresented by : Jayanth ChidanandAgenda:Feature detection mechanism is a diagnostic tool to quickly check and get assured of whether the architectural features enabled by software match with the given hardware implementation at an early stage of booting. It aims at mitigating the runtime-exceptions.I will be covering the implementation work completed so far and the impact ofReferences:TF-A Mailing List PostPatchesDocumentation=================================================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   (changed) When: Thu Apr 21, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organizer's request) Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 6 months

1
0
0 0

TF-A Tech-Forum Agenda for Thursday 21-Apr-22 at 4pm BST

by Joanna Farley

Topic: Feature Detection Mechanism Presented by : Jayanth Chidanand Agenda: Feature detection mechanism is a diagnostic tool to quickly check and get assured of whether the architectural features enabled by software match with the given hardware implementation at an early stage of booting. It aims at mitigating the runtime-exceptions. I will be covering the implementation work completed so far and the impact of References: TF-A Mailing List Post<https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…> Patches<https://review.trustedfirmware.org/q/topic:%22jc%252Fdetect_feat%22+(status…> Documentation<https://trustedfirmware-a.readthedocs.io/en/latest/search.html?q=FEATURE_DE…> ================================================= We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https://www.trustedfirmware.org/meetings/tf-a-…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https://zoom.us/j/9159704974&sa=D&source=calen…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https://zoom.us/u/ad27hc6t7h&sa=D&source=calen…>

3 years, 6 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Apr 21, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Topic: Feature Detection MechanismPresented by : Jayanth ChidanandAgenda:Feature detection mechanism is a diagnostic tool to quickly check and get assured of whether the architectural features enabled by software match with the given hardware implementation at an early stage of booting. It aims at mitigating the runtime-exceptions.I will be covering the implementation work completed so far and the impact ofReferences:TF-A Mailing List PostPatchesDocumentation=================================================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   (changed) When: Thu Apr 21, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 6 months

1
0
0 0

Status of MTE for bl31

by Okash Khawaja

Hi, I wanted to check the status of MTE support for bl31 itself. It seems like the support was added [1] for clang and armclang but I couldn't find the memory attribute to map pages as tag checked [2]. Is there something I missed? Thanks, Okash [1] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/… [2] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/…

3 years, 6 months

3
7
0 0

MTE support at S-EL1

by Jens Wiklander

Hi, I've started to experiment with MTE in OP-TEE at S-EL1. I've compiled TF-A with CTX_INCLUDE_MTE_REGS and I'm testing this on QEMU. Before trying to use MTE in OP-TEE I check id_aa64pfr1_el1 and skip MTE initializations if unavailable. This works as long as TF-A always is compiled with CTX_INCLUDE_MTE_REGS if MTE is available. If TF-A is compiled without CTX_INCLUDE_MTE_REGS OP-TEE will be trapped into EL3 when trying to access one of the MTE registers. I suppose this is because SCR_EL3.ATA is 0. Is there a way for OP-TEE to tell if the MTE registers are safe to access? Thanks, Jens

3 years, 6 months

2
2
0 0

TF-a would not handle PSCI_CPU_ON_AARCH64 if forwarded by a hypervisor

by Mushahid Hussain

Hi, I'm working on a hobby project: AARCH64 Hypervisor on Raspberry Pi 4b. I have a problem with trapping a psci smc. I'll explain everything and what steps I have followed. Right now, I'm implementing SMC trapping. I can successfully forward almost all SMCs except for PSCI_CPU_ON_AARCH64. Linux makes these SMCs to bring up secondary CPUs during booting. Here's what I'm trying to do: - trap the PSCI_CPU_ON_AARCH64 SMC, - preserve the entry_point address in global variable - replace the entrypoint with my entrypoint and make the smc to tf-a(or simply forward it.) - when secondary cpus come online at the given address, where I set their stack point and then eret the original address. Secondary cpus won't come online at the given address. Even if I don't change any arguments of CPU_ON smc and forward it as it is, the secondary cpus still won't come online. However, without trapping enabled(HCR_EL2.TSC=0), everything works fine. I tried to debug inside Trusted Firmware. I know that overall path for secondary CPU hotplug in is: CPU released from reset -> (ROM and possibly some other bootloader) -> bl31/aarch64/bl31_entrypoint.S:bl31_warm_entrypoint() -> lib/psci/psci_common.c:psci_warmboot_entrypoint() -> lib/psci/psci_on.c:psci_cpu_on_finish() -> rpi3_pwr_domain_on_finish() I printed at all these points in Trusted Firmware with and without trapping enabled. Here's what I found: Nothing gets printed anywhere in that path if trapping is enabled. However, without trapping enabled, I can print anywhere even in bl31_entrypoint.S:bl31_warm_entrypoint(). What could be the problem? Here's my code: https://github.com/SikkiLadho/Leo/blob/4f272eff39934058a7f989c91aad82eab810… -- Mushahid Hussain

3 years, 6 months

1
0
0 0

Cortex-X1 support

by Okash Khawaja

Hello, Are there any immediate plans to add support for Cortex-X1 in TF-A? If not then I'll be happy to submit CL for it. For start, it will cover a subset of errata workarounds. Then people can add more as needed. Let me know what you think. Thanks, Okash

3 years, 6 months

2
2
0 0

TF-A Tech Forum Agenda this week

by Joanna Farley

Session this week will be: * CCA Attestation and Measured boot * Presented by Tamas Ban * As a follow up to TF-A mailing list posting https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https://zoom.us/j/9159704974&sa=D&source=calen…> Meeting ID: 915 970 4974

3 years, 6 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Thu Apr 7, 2022 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed with this note: "Agenda for this week: Session this week will be: CCA Attestation and Measured boot Presented by Tamas Ban As a follow up to TF-A mailing list posting https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…" Title: TF-A Tech Forum Session this week will be:CCA Attestation and Measured bootPresented by Tamas BanAs a follow up to TF-A mailing list posting https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… 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   (changed) When: Thu Apr 7, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 6 months

1
0
0 0

[Feedback required] Feature detection mechanism

by Manish Pandey2

Hello All, We are sending this note, to notify you of all the implementation details related to the Architectural Features Detection Mechanism. Summary: This is a diagnostic tool, which is targeted to mitigate the runtime exceptions due to incorrect feature enablement. This is currently marked as experimental and disabled by default, but our target is to make it mandatory over the time. All the platform owners are expected to read the details(and review the patch) and give it a try by enabling this mechanism and share your thoughts/feedback or any questions to @Jayanth Dodderi Chidanand<mailto:JAYANTHDODDERI.CHIDANAND@arm.com> or me. Patches under Review: https://review.trustedfirmware.org/q/topic:jc/detect_feat Details: 1. What is Feature Detection Mechanism? * Feature Detection is a procedure/mechanism aimed at identifying the features which are enabled ( by software) and not detected/supported in the hardware. * It could be considered as a diagnostic tool to quickly check and get assured which features are not supported by the hardware at an early stage of booting. 2. Why do we need it? Currently, most of the feature-specific register's context management, save and restore routines are conditionally controlled with the ARM_ARCH_AT_LEAST macro, which is primarily causing exceptions under various scenarios like: * For a given version of the architecture, the optional and mandatory features control the access to various registers. If the given version of implementation does not support both, unconditional access to such registers leads to undefined behaviour. * Accessing registers without verifying their actual presence for the given implementation. In general, the problem is broader than just this specific case. We should not rely on ARM_ARCH_AT_LEAST macro to associate with an architecture extension but rather supply the individual ENABLE_FEAT_xxx option for each feature. Again, having individual build flags, won't resolve this completely. There is still room for error as users may unknowingly enable the flags. So, the build flags still need to be validated before performing any action guarded by them. This mechanism helps in resolving this issue completely. It assists in detecting the features which are not present in the platform but are enabled by software unknowingly. It prevents the runtime exception, due to the consequences already mentioned. 3. How have we designed and implemented it? We are introducing a tri-state approach for each feature build flag. From now on, the build flags take three values/states ( 0,1 or 2), and they imply as follows: The 3 states are: * ENABLE_FEAT_xxx = 0: The feature is disabled statically at compile time. * ENABLE_FEAT_xxx = 1: The feature is enabled and must be present in hardware. There will be hard panic if the feature is not present at cold boot. * ENABLE_FEAT_xxx = 2: The feature is enabled and detected at runtime Based on the value defined for each feature flag, they get detected either at boot-time or at runtime, respectively. For simplicity, let's take FEAT_HCX which is available in arch version 8.7. We provide a build option for enabling this feature, say "ENABLE_FEAT_HCX". * ENABLE_FEAT_HCX=0; The feature is disabled statically at compile time. * ENABLE_FEAT_HCX=1; The feature is enabled and must be present in hardware. There will be hard panic if the feature is not present at cold boot. i.e., we detect, whether the HCX feature is present in the PE, by reading its ID register and if not, panic will be called. Thereby at an early boot phase, we stop and report that FEAT_HCX is not supported by PE. * ENABLE_FEAT_HCX=2; The feature is enabled but dynamically enabled at runtime depending on hardware capability. Here, a feature detection check will happen during runtime. 4. What is the status of this implementation? Is it completely implemented and tested? We have divided the entire implementation into two phases. In phase-1 FEAT_STATES { 0, 1} are handled and FEAT_STATE{2} will be handled ahead. Currently, we are in phase-1 delivery, wherein we are introducing a procedure, which will read through all the enabled feature build flags, and if they are defined to state1, ENABLE_FEAT_XXX=1 the respective feature will be detected. 5. Which all features are considered here? TF-A supports most arm architectural features from v8.0 and upwards. Some are mandatory and some are optional features as per the Arm ARM docs. So, both ( Mandatory and optional features from v8.0) are detected under this mechanism. 6. Does this mechanism modify or impact any existing implementation related to any of the architectural features supported in TF-A? * Yes. * Ideally, TF-A enables the architectural features which are mandatory by default from a particular arch version and upwards ( as per Arm-ARM docs ) and disables the optional features by default and allows the platforms to make the decision on enabling the optional feature based on their requirements. * This pattern is followed for most of the features. However, there are some cases wherein optional features are enabled by default within TF-A ( Eg; FEAT_SPE, FEAT_SVE ), which shouldn't have been handled this way. * With the feature detection mechanism in place, as stated earlier the procedure runs through all the enabled features(optional and mandatory) and identifies them. * Now, FEAT_SPE and FEAT_SVE are optional features, which are enabled by default and when detected will not be identified by the PE, if it doesn't support it and panics during booting. * So, since we have enabled these optional features within the TF-A build system, it would panic and stop booting. * If we upstream this mechanism, all the partner's platforms will be impacted involuntarily. This problem will not be seen in other cases like: * Mandatory Feature: Let's say FEAT_FGT which is mandatory from the 8.6 version. So, if a platform is based on v8.6 it will implement this, and this feature will be detected. So no issue here. If the platform is based on v8.5, this FEAT_FGT is not enabled by the TF-A. It gets enabled from 8.6. So here, in this case, the feature is disabled so nothing to worry about. * Optional Feature: Let's say FEAT_NV2 which is an optional feature from arch version 8.4. is supported by TF-A. Since it is an optional one as per Arm ARM, TF-A implements and disables it by default and allows the platforms to decide and enable them as per their requirements. So here, if the platform enables it, it implies they are sure this feature is implemented. If not, this mechanism will help them by detecting it, so that they disable it in future. In general, this would not break the boot flow in all scenarios. But if the optional feature is enabled by TF-A itself, will stop the boot flow in most of scenarios. So, to avoid breaking change, we have decided to overlook such optional features for now and update our partners and get their feedback. Based on that, in future, we will disable these optional features which were enabled by default and will send another email to enable it explicitly according to their requirements. 7. What should the platforms be aware of, with the upstreaming of this mechanism? * Currently, we are introducing this entire implementation as an experimental mechanism, wherein we provide an explicit build flag (FEATURE_DETECTION) to enable the feature detection mechanism itself. We urge the platforms to enable this mechanism, test it and get used to its behaviour before it gets mandated. * So, for now, it wouldn't cause any issue. But our plan is to make sure this mechanism runs by default, as we want to mitigate the runtime Exceptions. As part of the 2.7 release, we are targeting to upstream this implementation and later, have some time window, wherein our partners get used to it and provide feedback as well. 8. Will there be any breakdown during runtime, with respect to any of the platforms? Yes. It's explained in detail above. 9. What is the long-term plan with this mechanism? When will this be completely implemented and tested end to end? We target it to be implemented full-fledged by EoY 2022, but it depends on the feedback received from our partners and get this done. Thanks

3 years, 6 months

1
0
0 0

ENABLE_PIE with clang

by Okash Khawaja

Hi, It seems like setting ENABLE_PIE=1 and compiling with clang/LLVM results in linker errors. E.g. compiling ti/k3 which has ENABLE_PIE=1, with clang and lld version 14.0.1 results in linker errors like "ld.lld: error: can't create dynamic relocation R_AARCH64_ABS64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output". Is this expected? If not, are there any plans to fix this? Thanks, Okash

3 years, 6 months

2
2
0 0

CCA Attestation and Measured boot

by Tamas Ban

Hi, In Arm CCA the Security Model strongly recommends implementing the CCA HES functionality to ensure the system security properties. A way to achieve this is to add a trusted subsystem to the system, which behaves like a secure enclave. In ARM reference design this trusted subsystem is called to Runtime Security Subsystem (RSS). RSS can execute a firmware component that implements the functional requirements of the HES. But its firmware is not restricted to be only the HES, other tenants are also allowed. The goal of the CCA HES is to provide fundamental services to the AP to ensure its security properties. These fundamental services include secure boot, measured boot and attestation, etc. You can find more information about the role of CCA HES and about its functional requirements in the Arm CCA Security Model [1]. In ARM reference design the CCA HES is going to be executed by RSS. CCA HES is based on TF-M. In this patch series [2] the AP side support of the CCA HES functionalities is going to be introduced: - Communication over an MHU channel between the AP and RSS. - Communication abstracted by the PSA API. So, AP can leverage standard PSA calls to invoke these services on the RSS. - CCA HES provides a measured boot backend. Measurements are taken during AP boot can be stored by RSS and retrieved as part of the CCA Platform Attestation token. - CCA Platform Attestation token can be requested from RSS. Currently, there is no publicly available FVP platform to test these patches, but it will be available later this year. Some limited testing is available on the AEM FVP. Here the RSS based measured boot backend is enabled and mocked version of the measured boot and attestation APIs are available. Due to the lack of RSS in the FVP, the APIs do not communicate to RSS, instead just print the measurements to the console and return to a hard-coded attestation token. [1] https://developer.arm.com/documentation/DEN0096/latest [2] https://review.trustedfirmware.org/q/topic:%2522rss/mboot-attest%2522 Best regards, Tamas Ban

3 years, 7 months

1
0
0 0

Mbed TLS GitHub migration

by dave.rodgman＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

3 years, 7 months

1
0
1 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 376885: Integer handling issues (NEGATIVE_RETURNS) ________________________________________________________________________________________________________ *** CID 376885: Integer handling issues (NEGATIVE_RETURNS) /drivers/st/clk/clk-stm32-core.c: 343 in _clk_stm32_set_parent() 337 if (parents->id_parents[sel] == (uint16_t)clkp) { 338 bool clk_was_enabled = _clk_stm32_is_enabled(priv, clk); 339 int err = 0; 340 341 /* Enable the parents (for glitch free mux) */ 342 _clk_stm32_enable(priv, clkp); >>> CID 376885: Integer handling issues (NEGATIVE_RETURNS) >>> "old_parent" is passed to a parameter that cannot be negative. 343 _clk_stm32_enable(priv, old_parent); 344 345 err = clk_mux_set_parent(priv, pid, sel); 346 347 _clk_stm32_disable(priv, old_parent); 348 ** CID 376884: Error handling issues (CHECKED_RETURN) /drivers/nxp/ddr/phy-gen2/phy.c: 2219 in load_fw() ________________________________________________________________________________________________________ *** CID 376884: Error handling issues (CHECKED_RETURN) /drivers/nxp/ddr/phy-gen2/phy.c: 2219 in load_fw() 2213 ERROR("Unsupported DIMM type\n"); 2214 return -EINVAL; 2215 } 2216 2217 size = PHY_GEN2_MAX_IMAGE_SIZE; 2218 image_buf = (uintptr_t)phy_gen2_fw_img_buf; >>> CID 376884: Error handling issues (CHECKED_RETURN) >>> Calling "mmap_add_dynamic_region" without checking return value (as is done elsewhere 14 out of 16 times). 2219 mmap_add_dynamic_region(phy_gen2_fw_img_buf, 2220 phy_gen2_fw_img_buf, 2221 PHY_GEN2_MAX_IMAGE_SIZE, 2222 MT_MEMORY | MT_RW | MT_SECURE); 2223 ret = img_loadr(imem_id, &image_buf, &size); 2224 if (ret != 0) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 7 months

1
0
1 0

Canceled event: TF-A Tech Forum @ Thu Mar 24, 2022 9am - 10am (MST) (tf-a@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been canceled. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this 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   When: Thu Mar 24, 2022 9am – 10am Mountain Standard Time - Phoenix Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org * don.harbin(a)linaro.org Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 7 months

1
0
0 0

TF-A Tech Forum

by Joanna Farley

Not sure if the cancellation has gone out but just confirming this Tech Forum is cancelled. Thanks Joanna From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 24 March 2022 Subject: TF-A Tech Forum You have been invited to the following event. TF-A Tech Forum When Thu Mar 24, 2022 4pm – 5pm United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher - creator • marek.bykowski(a)gmail.com • okash.khawaja(a)gmail.com • tf-a(a)lists.trustedfirmware.org more details »<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? Yes<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> - Maybe<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> - No<https://calendar.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tM…> more options »<https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…> Invitation from Google Calendar<https://calendar.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

3 years, 7 months

1
0
0 0

TF-A Tech Forum @ Thu Mar 24, 2022 4pm - 5pm (GMT) CANCELLED

by Joanna Farley

Just confirming that the TF-A Tech forum this week is cancelled due to no subject/topic. Thanks Joanna

3 years, 7 months

1
0
0 0

Invitation: TF-A Tech Forum @ Thu Mar 24, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

You have been invited to the following event. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this 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   When: Thu Mar 24, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 7 months

1
0
0 0

Canceled event: TF-A Tech Forum @ Thu Mar 24, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this 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   When: Thu Mar 24, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * 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 courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 7 months

1
0
0 0

TrustedFirmware Code of Conduct

by Don Harbin

Hi All, Please find the link to the TrustedFirmware Community Code of Conduct here: https://developer.trustedfirmware.org/w/collaboration/community_guidelines/… Trusted Firmware has a very diverse and global developer community. It is important that we adhere to the code of conduct in all our interactions. For some of you all this may be new and for others just a gentle reminder. In either case, if you have any questions, please feel free to reach out to me directly. And thanks to you all for your contributions to the TrustedFirmware community! Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years, 7 months

1
0
0 0

TF-A Technical Forum Session Agenda for Today

by Joanna Farley

I understand some people may not have seen the calendar invite for today’s Tech Forum session. It is in the archives but formatting has been lost so just confirming the agenda in plain email to the list. Joanna Agenda for Session on 10th March 2022 * Introduction to Arm DRTM specification and its support in TF-A * Stuart Yoder/Lucian Pau-Trifu will go through basic of Arm's DRTM specification, beta specification publicly released https://developer.arm.com/documentation/den0113/latest%C2%A0Manish * Pandey/Manish Badarkhe will go through implementation details and planned delivery in TF-A codebase. Details: * Dynamic Root of Trust for Measurement (DRTM) for Armv8-A is based on concepts from the TCG D-RTM Architecture. DRTM begins a new chain of trust by measuring and executing a protected payload which is in contrast to Static RTM(measured boot) where measurements are done at boot time. * Implementation of DRTM services in BL31 and various platform hooks required. Also, talk about initial support on FVP platform and limitations. We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https://www.trustedfirmware.org/meetings/tf-a-…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https://zoom.us/j/9159704974&sa=D&source=calen…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https://zoom.us/u/ad27hc6t7h&sa=D&source=calen…>

3 years, 7 months

1
1
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 376627: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 276 in pm_smc_handler() /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 553 in pm_smc_handler() ________________________________________________________________________________________________________ *** CID 376627: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 276 in pm_smc_handler() 270 SMC_RET1(handle, SMC_UNK); 271 272 pm_arg[0] = (uint32_t)x1; 273 pm_arg[1] = (uint32_t)(x1 >> 32); 274 pm_arg[2] = (uint32_t)x2; 275 pm_arg[3] = (uint32_t)(x2 >> 32); >>> CID 376627: (OVERRUN) >>> Overrunning array "pm_arg" of 4 4-byte elements at element index 4 (byte offset 19) using index "4". 276 pm_arg[4] = (uint32_t)x3; 277 278 api_id = smc_fid & FUNCID_NUM_MASK; 279 280 switch (api_id) { 281 /* PM API Functions */ /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 553 in pm_smc_handler() 547 SMC_RET2(handle, (uint64_t)ret | ((uint64_t)version << 32), 548 (uint64_t)bit_mask[0] | ((uint64_t)bit_mask[1] << 32)); 549 } 550 551 default: 552 /* Send request to the PMU */ >>> CID 376627: (OVERRUN) >>> Overrunning array "pm_arg" of 4 4-byte elements at element index 4 (byte offset 19) using index "4". 553 PM_PACK_PAYLOAD6(payload, api_id, pm_arg[0], pm_arg[1], 554 pm_arg[2], pm_arg[3], pm_arg[4]); 555 ret = pm_ipi_send_sync(primary_proc, payload, result, 556 PAYLOAD_ARG_CNT); 557 SMC_RET2(handle, (uint64_t)ret | ((uint64_t)result[0] << 32), 558 (uint64_t)result[1] | ((uint64_t)result[2] << 32)); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 7 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Mar 10, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Agenda for TF-A Tech Forum on 10th March 2022Introduction to Arm DRTM specification and its support in TF-AStuart Yoder/Lucian Pau-Trifu will go through basic of Arm's DRTM specification, beta specification publicly released https://developer.arm.com/documentation/den0113/latest M… Pandey/Manish Badarkhe will go through implementation details and planned delivery in TF-A codebase. Details:Dynamic Root of Trust for Measurement (DRTM) for Armv8-A is based on concepts from the TCG D-RTM Architecture. DRTM begins a new chain of trust by measuring and executing a protected payload which is in contrast to Static RTM(measured boot) where measurements are done at boot time.Implementation of DRTM services in BL31 and various platform hooks required. Also, talk about initial support on FVP platform and limitations.=========================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   (changed) When: Thu Mar 10, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 7 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 12 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 4 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 12 of 12 defect(s) ** CID 376586: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 207 in psci_get_stat() ________________________________________________________________________________________________________ *** CID 376586: Memory - illegal accesses (OVERRUN) /lib/psci/psci_stat.c: 207 in psci_get_stat() 201 if (pwrlvl == PSCI_INVALID_PWR_LVL) { 202 ERROR("Invalid target power level for PSCI statistics operation\n"); 203 panic(); 204 } 205 206 /* Get the index into the stats array */ >>> CID 376586: Memory - illegal accesses (OVERRUN) >>> Overrunning array "state_info.pwr_domain_state" of 2 bytes at byte offset 3 using index "pwrlvl" (which evaluates to 3). 207 local_state = state_info.pwr_domain_state[pwrlvl]; 208 stat_idx = get_stat_idx(local_state, pwrlvl); 209 210 if (pwrlvl > PSCI_CPU_PWR_LVL) { 211 /* Get the power domain index */ 212 parent_idx = SPECULATION_SAFE_VALUE(psci_cpu_pd_nodes[target_idx].parent_node); ** CID 376585: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 495 in amu_context_save() /lib/extensions/amu/aarch32/amu.c: 337 in amu_context_save() ________________________________________________________________________________________________________ *** CID 376585: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 495 in amu_context_save() 489 * Save the counters to the local context. 490 */ 491 492 isb(); /* Ensure counters have been stopped */ 493 494 for (i = 0U; i < amcgcr_el0_cg0nc; i++) { >>> CID 376585: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 495 ctx->group0_cnts[i] = amu_group0_cnt_read(i); 496 } 497 498 #if ENABLE_AMU_AUXILIARY_COUNTERS 499 for (i = 0U; i < amcgcr_el0_cg1nc; i++) { 500 ctx->group1_cnts[i] = amu_group1_cnt_read(i); /lib/extensions/amu/aarch32/amu.c: 337 in amu_context_save() 331 * Save the counters to the local context. 332 */ 333 334 isb(); /* Ensure counters have been stopped */ 335 336 for (i = 0U; i < amcgcr_cg0nc; i++) { >>> CID 376585: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 337 ctx->group0_cnts[i] = amu_group0_cnt_read(i); 338 } 339 340 #if ENABLE_AMU_AUXILIARY_COUNTERS 341 for (i = 0U; i < amcgcr_cg1nc; i++) { 342 ctx->group1_cnts[i] = amu_group1_cnt_read(i); ** CID 376584: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 585 in amu_context_restore() /lib/extensions/amu/aarch32/amu.c: 396 in amu_context_restore() ________________________________________________________________________________________________________ *** CID 376584: (OVERRUN) /lib/extensions/amu/aarch64/amu.c: 585 in amu_context_restore() 579 580 /* 581 * Restore the counter values from the local context. 582 */ 583 584 for (i = 0U; i < amcgcr_el0_cg0nc; i++) { >>> CID 376584: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 585 amu_group0_cnt_write(i, ctx->group0_cnts[i]); 586 } 587 588 #if ENABLE_AMU_AUXILIARY_COUNTERS 589 for (i = 0U; i < amcgcr_el0_cg1nc; i++) { 590 amu_group1_cnt_write(i, ctx->group1_cnts[i]); /lib/extensions/amu/aarch32/amu.c: 396 in amu_context_restore() 390 391 /* 392 * Restore the counter values from the local context. 393 */ 394 395 for (i = 0U; i < amcgcr_cg0nc; i++) { >>> CID 376584: (OVERRUN) >>> Overrunning array "ctx->group0_cnts" of 16 8-byte elements at element index 254 (byte offset 2039) using index "i" (which evaluates to 254). 396 amu_group0_cnt_write(i, ctx->group0_cnts[i]); 397 } 398 399 #if ENABLE_AMU_AUXILIARY_COUNTERS 400 for (i = 0U; i < amcgcr_cg1nc; i++) { 401 amu_group1_cnt_write(i, ctx->group1_cnts[i]); ** CID 376583: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 309 in ddr3_get_parameter() /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 298 in ddr3_get_parameter() ________________________________________________________________________________________________________ *** CID 376583: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 309 in ddr3_get_parameter() 303 tmp = ((DDR3_TWTR * nmhz + (nmhz >> 1) + 999) / 1000); 304 pdram_timing->twtr = max(4, tmp); 305 pdram_timing->trtw = DDR3_TRTW; 306 pdram_timing->tras_max = 9 * pdram_timing->trefi; 307 pdram_timing->tras_min = ((DDR3_TRAS * nmhz + (nmhz >> 1) + 999) 308 / 1000); >>> CID 376583: (OVERRUN) >>> Overrunning array "ddr3_trc_tfaw" of 22 2-byte elements at element index 31 (byte offset 63) using index "ddr_speed_bin" (which evaluates to 31). 309 pdram_timing->tfaw = 310 (((ddr3_trc_tfaw[ddr_speed_bin] & 0x0ff) * nmhz + 999) 311 / 1000); 312 /* tRFC, 90ns(512Mb),110ns(1Gb),160ns(2Gb),300ns(4Gb),350ns(8Gb) */ 313 if (ddr_capability_per_die <= 0x4000000) 314 tmp = DDR3_TRFC_512MBIT; /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 298 in ddr3_get_parameter() 292 else 293 pdram_timing->mr[0] = DDR3_BL8 294 | DDR3_CL(pdram_timing->cl) 295 | DDR3_WR(tmp); 296 tmp = ((DDR3_TRTP * nmhz + (nmhz >> 1) + 999) / 1000); 297 pdram_timing->trtp = max(4, tmp); >>> CID 376583: (OVERRUN) >>> Overrunning array "ddr3_trc_tfaw" of 22 2-byte elements at element index 31 (byte offset 63) using index "ddr_speed_bin" (which evaluates to 31). 298 pdram_timing->trc = 299 (((ddr3_trc_tfaw[ddr_speed_bin] >> 8) * nmhz + 999) / 1000); 300 tmp = ((DDR3_TRRD * nmhz + 999) / 1000); 301 pdram_timing->trrd = max(4, tmp); 302 pdram_timing->tccd = DDR3_TCCD; 303 tmp = ((DDR3_TWTR * nmhz + (nmhz >> 1) + 999) / 1000); ** CID 376582: (UNINIT) ________________________________________________________________________________________________________ *** CID 376582: (UNINIT) /drivers/st/clk/stm32mp1_clk.c: 1928 in stm32mp1_clk_init() 1922 if ((mmio_read_32(rcc_base + RCC_MP_RSTSCLRR) & 1923 RCC_MP_RSTSCLRR_MPUP0RSTF) != 0) { 1924 pll3_preserve = stm32mp1_check_pll_conf(_PLL3, 1925 clksrc[CLKSRC_PLL3], 1926 pllcfg[_PLL3], 1927 plloff[_PLL3]); >>> CID 376582: (UNINIT) >>> Using uninitialized value "*pllcfg[_PLL4]" when calling "stm32mp1_check_pll_conf". 1928 pll4_preserve = stm32mp1_check_pll_conf(_PLL4, 1929 clksrc[CLKSRC_PLL4], 1930 pllcfg[_PLL4], 1931 plloff[_PLL4]); 1932 } 1933 /* Don't initialize PLL4, when used by BOOTROM */ /drivers/st/clk/stm32mp1_clk.c: 1924 in stm32mp1_clk_init() 1918 if (ret != 0) { 1919 return ret; 1920 } 1921 1922 if ((mmio_read_32(rcc_base + RCC_MP_RSTSCLRR) & 1923 RCC_MP_RSTSCLRR_MPUP0RSTF) != 0) { >>> CID 376582: (UNINIT) >>> Using uninitialized value "*pllcfg[_PLL3]" when calling "stm32mp1_check_pll_conf". 1924 pll3_preserve = stm32mp1_check_pll_conf(_PLL3, 1925 clksrc[CLKSRC_PLL3], 1926 pllcfg[_PLL3], 1927 plloff[_PLL3]); 1928 pll4_preserve = stm32mp1_check_pll_conf(_PLL4, 1929 clksrc[CLKSRC_PLL4], ** CID 376581: Memory - illegal accesses (OVERRUN) /plat/brcm/common/brcm_io_storage.c: 389 in plat_get_image_source() ________________________________________________________________________________________________________ *** CID 376581: Memory - illegal accesses (OVERRUN) /plat/brcm/common/brcm_io_storage.c: 389 in plat_get_image_source() 383 boot_source = boot_source_get(); 384 if (image_id == FIP_IMAGE_ID) 385 policy = &boot_source_policies[boot_source]; 386 else 387 policy = &policies[image_id]; 388 >>> CID 376581: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 48 bytes at byte offset 168 by dereferencing pointer "policy". 389 result = policy->check(policy->image_spec); 390 if (result == 0) { 391 *image_spec = policy->image_spec; 392 *dev_handle = *(policy->dev_handle); 393 394 if (image_id == TRUSTED_BOOT_FW_CERT_ID) { ** CID 376580: Memory - illegal accesses (OVERRUN) /drivers/nxp/crypto/caam/src/caam.c: 245 in run_descriptor_jr() ________________________________________________________________________________________________________ *** CID 376580: Memory - illegal accesses (OVERRUN) /drivers/nxp/crypto/caam/src/caam.c: 245 in run_descriptor_jr() 239 int i = 0, ret = 0; 240 uint32_t *desc_addr = jobdesc->desc; 241 uint32_t desc_len = desc_length(jobdesc->desc); 242 uint32_t desc_word; 243 244 for (i = 0; i < desc_len; i++) { >>> CID 376580: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 64 4-byte elements at element index 126 (byte offset 507) by dereferencing pointer "desc_addr + i". 245 desc_word = desc_addr[i]; 246 VERBOSE("%x\n", desc_word); 247 sec_out32((uint32_t *)&desc_addr[i], desc_word); 248 } 249 dsb(); 250 ** CID 376579: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_client.c: 220 in pm_client_set_wakeup_sources() /plat/xilinx/zynqmp/pm_service/pm_client.c: 217 in pm_client_set_wakeup_sources() /plat/xilinx/versal/pm_service/pm_client.c: 149 in pm_client_set_wakeup_sources() /plat/xilinx/versal/pm_service/pm_client.c: 156 in pm_client_set_wakeup_sources() ________________________________________________________________________________________________________ *** CID 376579: (OVERRUN) /plat/xilinx/zynqmp/pm_service/pm_client.c: 220 in pm_client_set_wakeup_sources() 214 node = irq_to_pm_node(irq); 215 reg &= ~lowest_set; 216 217 if ((node != NODE_UNKNOWN) && 218 (!pm_wakeup_nodes_set[node])) { 219 ret = pm_set_wakeup_source(NODE_APU, node, 1); >>> CID 376579: (OVERRUN) >>> Overrunning array "pm_wakeup_nodes_set" of 78 bytes at byte offset 127 using index "node" (which evaluates to 127). 220 pm_wakeup_nodes_set[node] = !ret; 221 } 222 } 223 } 224 } 225 /plat/xilinx/zynqmp/pm_service/pm_client.c: 217 in pm_client_set_wakeup_sources() /plat/xilinx/versal/pm_service/pm_client.c: 149 in pm_client_set_wakeup_sources() 143 break; 144 } 145 146 node_idx = irq_to_pm_node_idx(irq); 147 reg &= ~lowest_set; 148 >>> CID 376579: (OVERRUN) >>> Overrunning array "pm_wakeup_nodes_set" of 84 bytes at byte offset 127 using index "node_idx" (which evaluates to 127). 149 if ((node_idx != XPM_NODEIDX_DEV_MIN) && 150 (pm_wakeup_nodes_set[node_idx] == 0U)) { 151 /* Get device ID from node index */ 152 device_id = PERIPH_DEVID(node_idx); 153 ret = pm_set_wakeup_source(node_id, 154 device_id, 1, /plat/xilinx/versal/pm_service/pm_client.c: 156 in pm_client_set_wakeup_sources() 150 (pm_wakeup_nodes_set[node_idx] == 0U)) { 151 /* Get device ID from node index */ 152 device_id = PERIPH_DEVID(node_idx); 153 ret = pm_set_wakeup_source(node_id, 154 device_id, 1, 155 SECURE_FLAG); >>> CID 376579: (OVERRUN) >>> Overrunning array "pm_wakeup_nodes_set" of 84 bytes at byte offset 127 using index "node_idx" (which evaluates to 127). 156 pm_wakeup_nodes_set[node_idx] = (uint8_t)(!ret); 157 } 158 } 159 } 160 } 161 ** CID 376578: Uninitialized variables (UNINIT) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 533 in pm_smc_handler() ________________________________________________________________________________________________________ *** CID 376578: Uninitialized variables (UNINIT) /plat/xilinx/zynqmp/pm_service/pm_svc_main.c: 533 in pm_smc_handler() 527 528 case PM_CLOCK_GETRATE: 529 { 530 uint64_t value; 531 532 ret = pm_clock_getrate(pm_arg[0], &value); >>> CID 376578: Uninitialized variables (UNINIT) >>> Using uninitialized value "value". 533 SMC_RET2(handle, (uint64_t)ret | 534 (((uint64_t)value & 0xFFFFFFFFU) << 32U), 535 (value >> 32U) & 0xFFFFFFFFU); 536 537 } 538 ** CID 376577: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 236 in ddr3_get_parameter() /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 235 in ddr3_get_parameter() ________________________________________________________________________________________________________ *** CID 376577: (OVERRUN) /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 236 in ddr3_get_parameter() 230 /* when dll bypss cl = cwl = 6 */ 231 if (nmhz < 300) { 232 pdram_timing->cl = 6; 233 pdram_timing->cwl = 6; 234 } else { 235 pdram_timing->cl = (ddr3_cl_cwl[ddr_speed_bin][tmp] >> 4) & 0xf; >>> CID 376577: (OVERRUN) >>> Overrunning array "ddr3_cl_cwl" of 22 7-byte elements at element index 31 (byte offset 223) using index "ddr_speed_bin" (which evaluates to 31). 236 pdram_timing->cwl = ddr3_cl_cwl[ddr_speed_bin][tmp] & 0xf; 237 } 238 239 switch (timing_config->dramds) { 240 case 40: 241 tmp = DDR3_DS_40; /plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c: 235 in ddr3_get_parameter() 229 230 /* when dll bypss cl = cwl = 6 */ 231 if (nmhz < 300) { 232 pdram_timing->cl = 6; 233 pdram_timing->cwl = 6; 234 } else { >>> CID 376577: (OVERRUN) >>> Overrunning array "ddr3_cl_cwl" of 22 7-byte elements at element index 31 (byte offset 223) using index "ddr_speed_bin" (which evaluates to 31). 235 pdram_timing->cl = (ddr3_cl_cwl[ddr_speed_bin][tmp] >> 4) & 0xf; 236 pdram_timing->cwl = ddr3_cl_cwl[ddr_speed_bin][tmp] & 0xf; 237 } 238 239 switch (timing_config->dramds) { 240 case 40: ** CID 376576: Uninitialized variables (UNINIT) /plat/mediatek/mt8195/plat_sip_calls.c: 48 in mediatek_plat_sip_handler() ________________________________________________________________________________________________________ *** CID 376576: Uninitialized variables (UNINIT) /plat/mediatek/mt8195/plat_sip_calls.c: 48 in mediatek_plat_sip_handler() 42 ret = dfd_smc_dispatcher(x1, x2, x3, x4); 43 SMC_RET1(handle, ret); 44 break; 45 case MTK_SIP_APUSYS_CONTROL_AARCH32: 46 case MTK_SIP_APUSYS_CONTROL_AARCH64: 47 ret = apusys_kernel_ctrl(x1, x2, x3, x4, &ret_val); >>> CID 376576: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret_val". 48 SMC_RET2(handle, ret, ret_val); 49 break; 50 default: 51 ERROR("%s: unhandled SMC (0x%x)\n", __func__, smc_fid); 52 break; 53 } 54 55 SMC_RET1(handle, SMC_UNK); ** CID 375635: Integer handling issues (BAD_SHIFT) /lib/zlib/inflate.c: 263 in inflatePrime() ________________________________________________________________________________________________________ *** CID 375635: Integer handling issues (BAD_SHIFT) /lib/zlib/inflate.c: 263 in inflatePrime() 257 state->hold = 0; 258 state->bits = 0; 259 return Z_OK; 260 } 261 if (bits > 16 || state->bits + (uInt)bits > 32) return Z_STREAM_ERROR; 262 value &= (1L << bits) - 1; >>> CID 375635: Integer handling issues (BAD_SHIFT) >>> In expression "(unsigned int)value << state->bits", left shifting by more than 31 bits has undefined behavior. The shift amount, "state->bits", is as much as 32. 263 state->hold += (unsigned)value << state->bits; 264 state->bits += (uInt)bits; 265 return Z_OK; 266 } 267 268 /* ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 8 months

1
0
0 0

[MPAM] Removing initialization of MPAM EL2 registers when EL2 is used

by Zelalem Aweke

Hi all, The small patch below [1] removes initialization of MPAM EL2 registers when EL2 is used, with the assumption that if an EL2 software exists it should perform the necessary initializations. Please take a look at the patch and let me know if this change affects any downstream projects. Thanks! Zelalem [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/13805/7

3 years, 8 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 376573: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 142 in intel_fpga_config_completed_write() ________________________________________________________________________________________________________ *** CID 376573: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 142 in intel_fpga_config_completed_write() 136 137 while (*count < 3) { 138 139 status = mailbox_read_response(job_id, 140 resp, &resp_len); 141 >>> CID 376573: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "resp_len < 0U". 142 if (resp_len < 0) 143 break; 144 145 max_blocks++; 146 147 if (mark_last_buffer_xfer_completed( ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 8 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Feb 24, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with this note: "No topic to be presented this week. Cancelling meeting." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this 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   When: Thu Feb 24, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * 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 courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 8 months

1
0
0 0

Re: please fix incomplete distclean Makefile target

by Nicolas Boulenguez

Hello. This threads originates in a trivial fix for the 'clean' Makefile target. All contributions, even cosmetic and/or from the outside world, must follow the same formal process. Apparently, the process fails for external contributors. The discussion is visible there: https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… At this moment, there were more people involved in the discussion than letters affected by the patch, so I was invited to switch to a private mail exchange. I was asked to describe the error messages, did so, and was forgotten ever since. Almost a year has passed, the patch is neither refused nor applied. The connection error still prevents some/all external contributions. The only effect of my request so far is that I have been obliged to create accounts on github and your gerrit instance. Is there hope for a more satisfying conclusion?

3 years, 8 months

2
1
0 0

Canceled event with note: TF-A Tech Forum @ Thu Feb 10, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with this note: "No topics prepared for this week." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this 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   When: Thu Feb 10, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * 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 courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 8 months

1
0
0 0

Is there any development roadmap(plan) for the Arm CCA features?

by Sangwan Kwon

Hi, I checked that TF-A supports FEAT_RME since v2.6. (https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html) And those are developed on rme_prototype branch. ( https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/log/?h=topics/r… ) But it is not updated since last year (September, 2021). I was wondering if there is a development plan or active branch about Arm CCA features (like RME RMM). BRs, Sangwan Kwon

3 years, 8 months

2
1
0 0

Cannot successfully jump to the UEFI Boot Loader in the normal world with the RME enabled FVP_Base_RevC_2xAEMvA

by Beom Heyn Kim

Hi, With RME enabled FVP_Base_RevC_2xAEMvA, we are trying to have TF-A's BL31 successfully exit EL3 and jump to a normal world boot firmware (edk2 UEFI boot loader) instead of tftf.bin. Yet, it fails with the following log messages (showing the last 3): INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x88000000 INFO: SPSR = 0x3c9 We could boot and run RMM and tftf.bin successfully following the instructions on the TF-A documentation page ( https://trustedfirmware-a.readthedocs.io/en/latest/components/realm-managem…). While keeping build and run commands same, we tried to just replace the tftf.bin with FVP_AARCH64_EFI.fd, the build artifact of the edk2-platform for ARM ( https://github.com/tianocore/edk2-platforms/tree/master/Platform/ARM) We checked both tftf.bin and FVP_AARCH64_EFI.fd cases result in the same entry point address 0x88000000. Yet, the latter stops after exiting EL3 as aforementioned, unlike tftf.bin which successfully proceeds to run some tests afterwards. Also, we found that FVP_AARCH64_EFI.fd can boot successfully with the same fast model but without RME enabled. What is the possible reason for this symptom and the necessary tweaks we should do to address this issue? What should we look for to get some clue? Cheers,

3 years, 8 months

2
1
0 0

Re: How secondary core(s) move from TF-A into Kernel space using PSCI - 4 x A55 ?

by Manish Pandey2

Hi Yusuf, I hope you have gone through https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… 1. Distinguishing between a cold boot and a warm boot. 2. In the case of a cold boot and the CPU being a secondary CPU, ensuring that the CPU is placed in a platform-specific state until the primary CPU performs the necessary steps to remove it from this state. 3. In the case of a warm boot, ensuring that the CPU jumps to a platform- specific address in the BL31 image in the same processor mode as it was when released from reset. Secondary cores are kept in TF-A holding pen until primary core makes a request to start secondary core(from OS through PSCI CPU_ON). On receiving this call primary breaks the condition which held secondary. For example, investigate a5ds platform's plat_secondary_cold_boot_setup() & a5ds_pwr_domain_on(). Platform also provides warm_boot_entrypoint (most platform uses bl31_warm_entrypoint) from where secondary starts execution. Primary core is responsible for platform initialization using platform helper functions mentioned https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… (make sure your platform has implemented all the mandatory hooks). Hope this helps thanks Manish ________________________________ From: Mohd Yusuf Abdul Hamid via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 07 February 2022 02:32 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] How secondary core(s) move from TF-A into Kernel space using PSCI - 4 x A55 ? Hi, I have been stuck at this problem for more than a week. Hopefully good folks here can help clarify a few things. Platform 4x Cortex A55 single cluster. What I got working: 1. I can boot single core kernel to shell using TFA bl31 Baremetal (bare minimum startup + platform specific SOC enablement, EL3) -> TFA bl31 -> Kernel 2. I added PSCI in DT and can see the hook trigger service and hotplug secondary core in. Secondary core woke up: 1. Bare minimum startup (skip SOC specific enablement) -> TFA bl31 -> go thru 'plat_secondary_cold_boot_setup' path, using 'RESET_TO_BL31:=1' Now, I am not sure how from there, the secondary core would jump to: a. If jump to kernel's 'secondary_holding_pen' it looks like it would drop from EL3 -> EL1 and wait (however at this point Core0 is already in cpu_idle) and won't continue a.1 For this case, I am also not sure why I hit "instruction abort" in core1 - from what I read MMU hasnt been set up, which is true. I also wonder at what point MMU is set up for this path in the secondary core? b. If jump to 'secondary_entry' I believe the core is still in EL3 at this point and I will get an exception at 'set_cpu_boot_mode_flag' c. If someone can summarize what are the minimum requirements for the secondary core to get set up before jumping to 'secondary_holding_pen'/'secondary_entry' whichever is applicable. Any pointers would be much appreciated. ps: I have access to Trace32. Mohd Yusuf Abdul Hamid

3 years, 8 months

2
1
0 0

What Doc / NDA doc do I need when I want to add a new platfrom in TF-A / OPTEE? (i.e., RK3566 )

by 起飞的老杨

Hello, Everyone, If I want to add a new platform support in TF-A for RK3566 as an example, what Documentation do I need to read. Using RK3399 as a contrast ( because most of RK3399 doc is opened in internet ), we already know this SoC is supported in OPTEE and TF-A. And I can get RK3399 Docs:* TRM V1.3 Part 1*, T*RM V1.3 Part2*, *TRM V1.4 Part 1*, *Datasheet V2.1*. I can see in *TRM chapter 16 System Security, *there are some descriptions about system security, and references to other system registers, like *SGRF, *etc, but it still seems to me insufficiently ( No SGRF description ) to finish a full support platform implementation in TF-A. Some people said I need to sign an NDA with Rockchip to get Security related part docs. But when I reach to Rockchip, they said all docs are opened already, No NDA options. When I talked to one partner/distributor of Rockchip, only security related doc is also some doc I can find on internet. So I am curious and confused, can I, as a third party developer, develop a new platform implementation for TF-A / OPTEE ( specially for Rockchip Platform )? Thanks

3 years, 8 months

2
2
0 0

How secondary core(s) move from TF-A into Kernel space using PSCI - 4 x A55 ?

by Mohd Yusuf Abdul Hamid

Hi, I have been stuck at this problem for more than a week. Hopefully good folks here can help clarify a few things. Platform 4x Cortex A55 single cluster. What I got working: 1. I can boot single core kernel to shell using TFA bl31 Baremetal (bare minimum startup + platform specific SOC enablement, EL3) -> TFA bl31 -> Kernel 2. I added PSCI in DT and can see the hook trigger service and hotplug secondary core in. Secondary core woke up: 1. Bare minimum startup (skip SOC specific enablement) -> TFA bl31 -> go thru 'plat_secondary_cold_boot_setup' path, using 'RESET_TO_BL31:=1' Now, I am not sure how from there, the secondary core would jump to: a. If jump to kernel's 'secondary_holding_pen' it looks like it would drop from EL3 -> EL1 and wait (however at this point Core0 is already in cpu_idle) and won't continue a.1 For this case, I am also not sure why I hit "instruction abort" in core1 - from what I read MMU hasnt been set up, which is true. I also wonder at what point MMU is set up for this path in the secondary core? b. If jump to 'secondary_entry' I believe the core is still in EL3 at this point and I will get an exception at 'set_cpu_boot_mode_flag' c. If someone can summarize what are the minimum requirements for the secondary core to get set up before jumping to 'secondary_holding_pen'/'secondary_entry' whichever is applicable. Any pointers would be much appreciated. ps: I have access to Trace32. Mohd Yusuf Abdul Hamid

3 years, 8 months

1
0
0 0

Re: GIC-600 errata 1717652: missed wake requests

by Bipin Ravi

Hi Okash, In TF-A project, we haven't supported errata patches for system IP's like GIC-600 until now. We typically support Cat B errata patches for Arm CPU implementations that are made public. Additionally we also support DSU errata patches for the TF-A supported CPUs as applicable. But we are more than happy to support any code reviews required for the implementation of the below said errata. Thanks, Bipin -----Original Message----- From: tf-a-request(a)lists.trustedfirmware.org <tf-a-request(a)lists.trustedfirmware.org> Sent: Thursday, January 27, 2022 6:00 PM To: tf-a(a)lists.trustedfirmware.org Subject: TF-A Digest, Vol 37, Issue 16 1. GIC-600 errata 1717652: missed wake requests (Okash Khawaja) ---------------------------------------------------------------------- Message: 1 Date: Thu, 27 Jan 2022 13:36:32 +0000 From: Okash Khawaja <okash(a)google.com> Subject: [TF-A] GIC-600 errata 1717652: missed wake requests To: tf-a(a)lists.trustedfirmware.org Message-ID: <CAGjWKv6TTLVvF7GfsmY76QFjSzcSX8DqPuPukJQAOH-AqAvuLg(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hi, It seems like TF-A's GIC600 driver currently doesn't have support for the Cat B errata 1717652 "Wake_request may not be delivered if multiple cores are woken by PPIs at the same time". Are there plans to support this? Thanks, Okash ------------------------------ Subject: Digest Footer TF-A mailing list -- tf-a(a)lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org ------------------------------ End of TF-A Digest, Vol 37, Issue 16 ************************************

3 years, 9 months

2
1
1 0

GIC-600 errata 1717652: missed wake requests

by Okash Khawaja

Hi, It seems like TF-A's GIC600 driver currently doesn't have support for the Cat B errata 1717652 "Wake_request may not be delivered if multiple cores are woken by PPIs at the same time". Are there plans to support this? Thanks, Okash

3 years, 9 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Jan 27, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Agenda for Session on 27th January 2020Introduction of Arm CCA Context ManagementSession Presented by: Manish Pandey, Soby Mathew and Zelalem AwekeDetails: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3.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   (changed) When: Thu Jan 27, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 9 months

1
0
1 0

TF-A Technical Forum Session Agenda this week

by Joanna Farley

Agenda for Session on 27th January 2020 * Introduction of Arm CCA Context Management * Session Presented by: Manish Pandey, Soby Mathew and Zelalem Aweke * Details: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3. We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https://www.trustedfirmware.org/meetings/tf-a-…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https://zoom.us/j/9159704974&sa=D&source=calen…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https://zoom.us/u/ad27hc6t7h&sa=D&source=calen…>

3 years, 9 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Jan 27, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum Agenda for Session on 27th January 2020introduction of Arm CCA Context ManagementSession Presented by: Manish Pandy, Soby Mathew and Zelalem AwekeDetails: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3.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   (changed) When: Thu Jan 27, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 9 months

1
0
0 0

RFC for context management refactoring in TF-A

by Soby Mathew

Hello Everyone, We have a proposal to refactor the Context management framework in TF-A and an RFC is pushed for review here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/13651 . The abstract of the RFC is given below: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3. The plus point here is that many of the design principles are already adhered to in one way or other in the current the implementation so much of the work can be done in an incremental fashion without much disruption. Along with @Zelalem Aweke<mailto:Zelalem.Aweke@arm.com> and @Manish Pandey2<mailto:Manish.Pandey2@arm.com>, we hope to discuss the this RFC and how this translates to code changes in TF-A during the Tech Forum this week. Best Regards Soby Mathew

3 years, 9 months

1
0
0 0

About arm_validate_ns_entrypoint in arm_pm.c

by Ming Huang

Hi, arm_validate_ns_entrypoint() in plat/arm/common/arm_pm.c check ARM_NS_DRAM1_BASE and ARM_NS_DRAM2_BASE only, for some platform there are include more than two non-secure dram areas. It will bring dependencies between TF-A and physical memory space which can get from uefi atfer memory initialization, if arm_validate_ns_entrypoint() include the entire physical memory space. In my mind, the kernel should guarantee the validity of entry point. So why this check is need? Thanks, Ming

3 years, 9 months

3
3
0 0

imx8mm-evk does not boot kernel 5.16 with mainline TF-A

by Fabio Estevam

Hi, I am running U-Boot 2022.01 on imx8mm-evk. If I build the NXP vendor-based TF-A (imx_5.4.47_2.2.0) I am able to boot kernel 5.16 just fine. However, if I use the upstream TF-A (v2.5 or v2.6), the kernel fails to boot most of the attempts. Peng, Jacky, Could you please try booting kernel 5.16 + U-Boot 2022.01 built with TF-A v2.6? What is missing in upstream TF-A to be able to boot kernel 5.16? Thanks, Fabio Estevam

3 years, 9 months

2
1
0 0

fw update & anti-rollback versioning

by Etienne CARRIERE

Dear all, (and may the new year be happy to you and your beloved) In the course of evaluating the FW update flows for systems with FIP images, we identified the following requirements: Req1: The FIP image, or the components in the FIP, must have a version field. Each version field will be compared against the anti-rollback counter of the platform that the FIP or its component is bound to. Req2: We must be able to increment the FIP version field (though a FIP image FW update) without affecting the anti-rollback counter value. The anti-rollback counter should be incremented only for security updates upon explicit request. Req3: The version field should be present even if the FIP does not contain image certificates. Currently the FIP carries a version field in the different certificates, the anti-rollback counters are updated every time the root certificate value increased. This is not flexible enough and does not allow trial/acceptance of updates. Can we open a discussion on how to enhance the version/anti-rollback counter update in TF-A? Best regards, Etienne Carriere ST Restricted

3 years, 9 months

4
6
0 0

TF-A (inc Hafnium) Tech Forum this week

by Joanna Farley

Hi Everyone, Welcome to 2022! To start off this year’s Tech Forum’s we will use the session this week to follow up on two ongoing email list discussion subjects: * Hafnium Build and Tooling Options. * Discussion led by Olivier Deprez. * Covering recent changes to the Hafnium project that has neem announced on the Hafnium mailing list https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmwa…<https://www.google.com/url?q=https%3A%2F%2Flists.trustedfirmware.org%2Farch…> * Firmware Update and Anti-Rollback Versioning * Discussion led by Manish Badarkhe and Manish Pandey2 * An opportunity to discuss the recent email thread on this topic on the TF-A mailing list. https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…<https://www.google.com/url?q=https%3A%2F%2Flists.trustedfirmware.org%2Farch…> If you don’t have the invite which just been updated the meeting details are: TF-A Tech Forum Thursday, January 13⋅4:00 – 5:00pm GMT Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https://zoom.us/j/9159704974&sa=D&source=calen…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https://zoom.us/u/ad27hc6t7h&sa=D&source=calen…> Thanks all Joanna

3 years, 9 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Jan 13, 2022 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been changed. Title: TF-A Tech Forum The Tech Forum this week will cover two discussion subjects:Hafnium Build and Tooling Options.  Discussion led by Olivier Deprez.Covering recent changes to the Hafnium project that has neem announced on the Hafnium mailing list https://lists.trustedfirmware.org/archives/list/hafnium@lists.trustedfirmwa… Update and Anti-Rollback VersioningDiscussion led by Manish Badarkhe and Manish Pandey2An opportunity to discuss the recent email thread on this topic on the TF-A mailing list. https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… 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   (changed) When: Thu Jan 13, 2022 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 9 months

1
0
0 0

MISRA C compliance spreadsheet access permission

by Lim, Jit Loon

Hi TF-A committee, We are trying to access to the MISRA C spreadsheet mentioned over here. [cid:image001.jpg@01D806BE.A535F7C0] https://developer.trustedfirmware.org/file/download/lamajxif3w7c4mpjeoo5/PH… However, we are facing issue to open the spreadsheet and we are getting "Invalid Authorization". [cid:image002.jpg@01D806BE.A535F7C0] After we click on the "Continue", the website show Restricted File and we have no access permission. [cid:image003.jpg@01D806BE.A535F7C0] Thus, we would like to get your help to assist us on how to obtain the spreadsheet. Hope to hear from you soon. Thanks Best Regards JL Lim (Benjamin)

3 years, 9 months

2
2
0 0

A problem about assert failed in TF-A

by Chenxu Wang

Hi all, I am running FVP with 2CPUs, Cactus SP (SEL1), Hafnium (SEL2) and KVM VHE. Sometimes I send the "FFA_MSG_SEND_DIRECT_REQ" smc call from KVM (I fill 0x8400006f in x0, then VMID and SP ID in x1, let x2 as 0). It says assert failed, like this: ASSERT: lib/el3_runtime/aarch64/context_mgmt.c:651 BACKTRACE: START: assert 0: EL3: 0x4005cac 1: EL3: 0x400323c 2: EL3: 0x400620c 3: EL3: 0x400e180 4: EL3: 0x4005a94 BACKTRACE: END: assert After I check the bl31.dump, I notice that: when services/std_svc/spmd/spmd_main.c sends the FFA call (from NS to S) via "spmd_smc_forward(smc_fid, secure_origin,x1, x2, x3, x4, handle)", it will go to cm_el1_sysregs_context_restore(secure_state_out) and cm_el2_sysregs_context_restore(secure_state_out), then it will assert the cm_get_context(). it gets the NULL context, so assert failed. Before the problem appeared, I have modified many codes on a dirty TF-A v2.4 (commit hash is 0aa70f4c4c023ca58dea2d093d3c08c69b652113), Hafnium and TF-A-TESTS. I also mail with Hafnium MailList, they consider it can be a problem in EL3. Such assert is NOT ALWAYS failed. I mean, maybe when I run FVP and send "smc" now, it is failed. But when I shut down, run FVP, and send the same instruction with the same parameter again, it is OK. I want to know, what is the possible reasons for suddenly losing the secure context. Can you give me some advice on debugging? e.g., where should I check? Need I provide more info? Sincerely, Wang

3 years, 10 months

3
4
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 374565: Error handling issues (CHECKED_RETURN) /drivers/st/mmc/stm32_sdmmc2.c: 176 in stm32_sdmmc2_init() ________________________________________________________________________________________________________ *** CID 374565: Error handling issues (CHECKED_RETURN) /drivers/st/mmc/stm32_sdmmc2.c: 176 in stm32_sdmmc2_init() 170 171 mmio_write_32(base + SDMMC_POWER, 172 SDMMC_POWER_PWRCTRL_PWR_CYCLE | sdmmc2_params.dirpol); 173 mdelay(POWER_CYCLE_DELAY); 174 175 if (sdmmc2_params.vmmc_regu != NULL) { >>> CID 374565: Error handling issues (CHECKED_RETURN) >>> Calling "regulator_enable" without checking return value (as is done elsewhere 6 out of 7 times). 176 regulator_enable(sdmmc2_params.vmmc_regu); 177 } 178 179 mdelay(VCC_POWER_ON_DELAY); 180 181 mmio_write_32(base + SDMMC_POWER, sdmmc2_params.dirpol); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 10 months

1
0
0 0

How to change the address of region "RAM" in BL31?

by Chenxu Wang

Hi all, I want to add some big data structures in BL31 (e.g., create a large uint32_t array). Also, I reserve a secure memory space (assume it is 0xa000_0000 - 0xb000_0000) by configuring TZASC. Now, the BL31 says build/fvp/debug/bl31/bl31.elf section `.bss' will not fit in region `RAM' aarch64-none-elf-ld: BL31 image has exceeded its limit. aarch64-none-elf-ld: region `RAM' overflowed by 458752 bytes It looks like that the previous RAM cannot hold my big data structures. If I want to add my reserved region into RAM (so I may allocate these data into the reserved region), what should I do? Sincerely, Wang

3 years, 10 months

2
1
0 0

Re: [TF-A] [TF-M] Tip on cloning TF-M on OS X Monterey

by Gyorgy Szing

Hi, Please allow me to add some more details. Also posting to the TF-A list, as all tf.org repositories are affected. The root cause of this issue is OpenSSH dropping support for SHA-1 RSA signatures with the 8.8 release, and thus any OS (or git client) coming with a recent version is affected. I.e. the newest git for windows is affected too, and so are “top notch” Linux distributions like Arch. For details see the “Potentially-incompatible changes” chapter here: https://www.openssh.com/releasenotes.html As the above page states “Incompatibility is more likely when connecting to older SSH implementations…”, and thus a server-side update would eliminate the problem. Till that happens the page above list multiple client-side workarounds. (It is possible to amend the ssh config in a way that fixes all repositories.) /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: December 15, 2021 13:06 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Tip on cloning TF-M on OS X Monterey I recently switched to a new MBP that ships with OS X Monterey, and on both 12.0 and 12.1 (released this week) git clone seems to be broken when you're using HTTP rather than SSH: digital envelope routines:CRYPTO_internal:bad key length In order to clone TF-M, I had to make the following changes. 1. Add these details to $HOME/.ssh/config (microbuilder being my github username, associated with my TF-M account): Host trustedfirmware.org<http://trustedfirmware.org> User microbuilder Hostname review.trustedfirmware.org<http://review.trustedfirmware.org> Port 29418 IdentityFile ~/.ssh/id_rsa IdentitiesOnly yes 2. Then try to clone with: $ git clone trustedfirmware.org:/TF-M/trusted-firmware-m.git This fails, however, since it tries to clone tf-m-tests.git, so: 3. Edit lib/ext/tf-m-tests/fetch_repo.cmake, changing: FetchContent_Declare(tfm_test_repo GIT_REPOSITORY trustedfirmware.org:TF-M/tf-m-tests.git # GIT_REPOSITORY https://git.trustedfirmware.org/TF-M/tf-m-tests.git GIT_TAG ${TFM_TEST_REPO_VERSION} GIT_PROGRESS TRUE ) This let me at least clone TF-M until the issues with HTTP-based cloning are fixed. Hope this is useful to someone else working on OS X natively. Kevin

3 years, 10 months

1
0
0 0

FCONF warning for TOS_FW_CONFIG

by Yann Gautier

Hi, On STM32MP1, we'd like BL2 to be agnostic of what BL32 is in the FIP. It can be either OP-TEE or TF-A SP_min. But on STM32MP1, SP_min needs a device tree file (TOS_FW_CONFIG_ID), whereas OP-TEE doesn't use this separate DT image. As TOS_FW_CONFIG_ID is in list of images to be loaded by BL2, we then have a warning message in case OP-TEE is used: WARNING: FCONF: Invalid config id 26 I'd like to silence this warning with this kind of patch: diff --git a/lib/fconf/fconf_dyn_cfg_getter.c b/lib/fconf/fconf_dyn_cfg_getter.c index 25dd7f9eda..f7e9834c3b 100644 --- a/lib/fconf/fconf_dyn_cfg_getter.c +++ b/lib/fconf/fconf_dyn_cfg_getter.c @@ -51,7 +51,11 @@ struct dyn_cfg_dtb_info_t *dyn_cfg_dtb_info_getter(unsigned int config_id) } } - WARN("FCONF: Invalid config id %u\n", config_id); + if (config_id == TOS_FW_CONFIG_ID) { + VERBOSE("FCONF: No TOS_FW_CONFIG image\n"); + } else { + WARN("FCONF: Invalid config id %u\n", config_id); + } return NULL; } I can change the VERBOSE message to INFO. Do you think it is OK if I push the patch? Thanks, Yann

3 years, 10 months

2
6
0 0

Cancelling Tech-Forums 16th and 30th December 2021

by Joanna Farley

I’m not sure if the cancellations have been sent from the trustedfirmware.org calendar system so confirming that they are cancelled to the list. Next scheduled Tech Forum is 13th January 2022. Joanna

3 years, 10 months

1
0
0 0

How to load some images in BL31?

by Chenxu Wang

Hi all, I want to load a specific image in BL31. But when I call load_auth_image(). It says "in function `load_image': trusted-firmware-a/common/bl_common.c:87: undefined reference to `plat_get_image_source'" Also, the io_read, io_size and etc. are undefined reference. I find other BL files (bl1, bl2) will call the load_auth_image() in their main functions or sub-functions. If I want to implement it on BL31, what should I do? Should I modify the Makefile? Sincerely, Wang

3 years, 10 months

2
1
0 0

Re: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Joanna Farley

Hi Everyone, this is the TF-A Tech Forum meeting agenda for this week. Thanks Joanna Subject: ‘Measured Boot Driver - refactor and Critical Data measurement design’ Presented by: Manish Badarkhe 1. A brief overview of Measured Boot driver refactoring done in TF-A Bootloader 2. Discuss a few gaps observed in the Measured Boot driver and patches up-streamed for it 3. Discuss the list of critical data observed in TF-A firmware and its measurement design From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 2 December 2021 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) Regular bi weekly Trustedfirmware.org TF-A TechForum. I host this and its where we go to our community and present/discuss things live in public. Past sessions listed here https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ Mailing list here if you want to subscribe. https://lists.trustedfirmware.org/mailman/listinfo/tf-a Project page here: https://www.trustedfirmware.org/projects/tf-a/ Abhishek never attended any of these. Cancelled if there is no topic to present. From: linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com When: 16:00 - 17:00 18 June 2020 Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. ________________________________ From: Trusted Firmware Public Meetings Sent: Sunday, June 14, 2020 5:21:25 PM (UTC) Coordinated Universal Time To: Trusted Firmware Public Meetings; tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a(a)lists.trustedfirmware.org) When: Occurs on Thursday every other week from 4:00 PM to 5:00 PM effective 6/18/2020. Europe/London Where: You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>.

3 years, 11 months

1
0
0 0

Trusted Firmware version 2.6 is now available

by Bipin Ravi

Hi all, We are pleased to announce the formal release of Trusted Firmware-A version 2.6, Trusted Firmware-A Tests version 2.6, Hafnium version 2.6 and TF-A OpenCI Scripts 2.6 Releases involving the tagging of multiple sub repositories. These went live on 24th November 2021. Notable Features of the Version 2.6 Release across repositories are as follows: * v8-R64 Upstream support, trusted-boot (BL1) only * RME patches (4 world support) * Hunter & Hayes CPU support * Demeter (Makalu ELP for Infra) CPU support * ARM v9.0-A ETE V1.0 * ARM v9.1-A ETE V1.1 * Armv9 RME support * Generic Firmware Update support * Measured Boot Enhancements * MPMM AMU support SME (Mortlach) for non-secure world (FEAT_SME) * Security hardening LLVM/clang support. * FF-A v1.1 notifications support. * FF-A v1.1 interrupt handling support. * S-EL0 partitions (through VHE in the secure world). * SPM support for saving/restoring the normal world SVE live state. * Build system update to LLVM/Clang 12. * Updates to FF-A Setup and discovery. * FF-A compliance fixes. * Threat model introduced for SPMC at SEL2 * Eight new partner and Arm platforms support added Please refer to the TF-A [1], Hafnium [2] and TF-A Tests [3] changelogs for the complete summary of changes the previous release. The test plan and results [4] for the v2.6 release captures the release test activities. TF-A [5], TF-A Test [6], Hafnium [7] and TF-A OpenCI Scripts [8] repositories are available [1] https://trustedfirmware-a.readthedocs.io/en/v2.6/ [2] https://review.trustedfirmware.org/plugins/gitiles/hafnium/hafnium/+/HEAD/d… [3] https://trustedfirmware-a-tests.readthedocs.io/en/v2.6/ [4] https://confluence.arm.com/display/BSGSoftware/TF-A+v2.6+Test+Plan+and+Resu… [5] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.6 [6] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.6 [7] https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.6 [8] https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.6 Thanks & best regards, [cid:image001.jpg@01D7E120.C34F0DA0] Bipin Ravi | Principal Design Engineer Bipin.Ravi(a)arm.com<mailto:Bipin.Ravi@arm.com> | Skype: Bipin.Ravi.ARM Direct: +1-512-225 -1071 | Mobile: +1-214-212-0794 5707 Southwest Parkway, Suite 100, Austin, TX 78735

3 years, 11 months

1
0
0 0

Linux as BL33

by Ramon Fried

Hi. I'm trying to run on our new platform Linux as BL33, preloaded to DDR. currently simulated over QEMU. I think that BL31 started BL33 in EL0, which cause problems: QEMU outputs this message: (complete log below) Exception return from AArch64 EL3 to AArch64 EL0 PC 0x800080000 What could I have done wrong in the configuration that caused it ? What should I check ? Thanks ! Ramon. NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.5(debug):v2.5-61-g84d7d6a30-dirty NOTICE: BL1: Built : 14:53:02, Nov 21 2021 INFO: BL1: RAM 0x15500000 - 0x15513000 WARNING: BL1: neoverse_n1: CPU workaround for 1946160 was missing! INFO: BL1: Loading BL2 INFO: Using mmap INFO: Using FIP INFO: Loading image id=1 at address 0x14300000 INFO: Image id=1 loaded: 0x14300000 - 0x143052d1 INFO: bl1_mem_layout->total_base = 0x14000000x NOTICE: BL1: Booting BL2 INFO: Entry point address = 0x14300000 INFO: SPSR = 0x3c5 Exception return from AArch64 EL3 to AArch64 EL1 PC 0x14300000 INFO: BL1 inherited memory layout: 0x14000000 [size = 22020096] NOTICE: BL2: v2.5(debug):v2.5-61-g84d7d6a30-dirty NOTICE: BL2: Built : 14:53:02, Nov 21 2021 INFO: BL2: Skip loading image id 23 INFO: BL2: Doing platform setup INFO: BL2: Loading image id 3 INFO: Using mmap INFO: Using FIP INFO: Loading image id=3 at address 0x800000000 INFO: Image id=3 loaded: 0x800000000 - 0x8000080a9 INFO: BL2: Skip loading image id 5 Taking exception 13 [Secure Monitor Call] ...from EL1 to EL3 ...with ESR 0x17/0x5e000000 ...with ELR 0x14302a04 ...to EL3 PC 0x5400 PSTATE 0x3cd NOTICE: BL1: Booting BL31 INFO: Entry point address = 0x800000000 INFO: SPSR = 0x3cd Exception return from AArch64 EL3 to AArch64 EL3 PC 0x800000000 INFO: Boot BL33 from 0x800080000 for 0 Bytes NOTICE: BL31: v2.5(debug):v2.5-61-g84d7d6a30-dirty NOTICE: BL31: Built : 14:53:04, Nov 21 2021 INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: Maximum SPI INTID supported: 63 INFO: BL31: Initializing runtime services WARNING: BL31: neoverse_n1: CPU workaround for 1946160 was missing! INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x800080000 INFO: SPSR = 0x0 Exception return from AArch64 EL3 to AArch64 EL0 PC 0x800080000 Taking exception 1 [Undefined Instruction] ...from EL0 to EL1 ...with ESR 0x18/0x6232c061 ...with ELR 0x8000b7164 ...to EL1 PC 0x400 PSTATE 0x3c5 Taking exception 4 [Data Abort]

3 years, 11 months

2
2
0 0

Canceled event with note: TF-A Tech Forum @ Thu Nov 18, 2021 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with this note: "Cancelling TF-A Tech Forum this week as the team have nothing to present. We expect to have a topic for December 2nd." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this 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   When: Thu Nov 18, 2021 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * 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 courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 11 months

1
0
0 0

Re: [TF-A] Missing CPU workaround warning message

by Varun Wadekar

Hi Pali, My understanding of the errata reporting mechanism is that some erratas are always checked during CPU boot. If the corresponding MACRO (ERRATA_A53_*) is disabled, then the ERRATA_MISSING code is reported. I would be concerned if the CPU is affected by the errata. If the errata needs to be enabled, the fix would be to enable the ERRATA_A53_* from the platform makefile. Hope this helps. -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Pali Rohár via TF-A Sent: Wednesday, July 7, 2021 9:11 PM To: Olivier Deprez <Olivier.Deprez(a)arm.com>; Bipin Ravi <Bipin.Ravi(a)arm.com>; tf-a(a)lists.trustedfirmware.org Cc: Konstantin Porotchkin <kostap(a)marvell.com>; Marek Behún <marek.behun(a)nic.cz> Subject: Re: [TF-A] Missing CPU workaround warning message External email: Use caution opening links or attachments Hello! Could somebody from TF-A helps with these two topics? I would really need to know if "missing errata warnings" debug message is some critical and needs to be fixed (and how?) or it is just a debug message and therefore should not be a warning... On Monday 28 June 2021 17:11:18 Pali Rohár wrote: > On Monday 28 June 2021 14:03:06 Olivier Deprez wrote: > > Hi, > > > > Is the question strictly related to this platform not implementing the mentioned errata (for which a platform change can be emitted)? > > Hello! The first question is if this is an issue that CPU workaround > is missing. And if yes (which seems to be) how big issue it is? And > how to resolve it? > > > Or is it more generally that those "missing errata warnings" are not printed in release mode? > > Assuming the latter, it looks to me it is the integrator mistake to not include the appropriate mitigations at development phase (hence while using debug mode for building TF-A). > > Then when the device is deployed (hence most often built for release mode), if this message is printed it is an indication for a malicious agent that such attack vector through mis-implemented errata is possible. So the consequence is possibly even worst than just "missing" to include the errata. > > > > Other TF-Aers (Bipin?) may have other opinions? > > And this is a second question. If missing CPU workaround is an issue, > should not be it printed also in release build? > > Also I see that in release builds are omitted not only messages about > missing CPU workarounds, but basically _all_ warning messages. But > notice messages are _not_ omitted. Which seems strange as in most > cases notice message has lower priority than warning message. > > > > > Regards, > > Olivier. > > > > ________________________________________ > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > > Pali Rohár via TF-A <tf-a(a)lists.trustedfirmware.org> > > Sent: 28 June 2021 15:36 > > To: tf-a(a)lists.trustedfirmware.org > > Cc: Konstantin Porotchkin; Marek Behún > > Subject: [TF-A] Missing CPU workaround warning message > > > > Hello! If TF-A for Marvell Armada 3720 platform is compiled in debug > > mode then at runtime it prints following warning messages: > > > > WARNING: BL1: cortex_a53: CPU workaround for 855873 was missing! > > WARNING: BL1: cortex_a53: CPU workaround for 1530924 was missing! > > > > These lines are not printed in non-debug mode. It is an issue? > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > sts.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-a&data=04%7C01 > > %7Cvwadekar%40nvidia.com%7Cb3605175f552468740e708d941836783%7C43083d > > 15727340c1b7db39efd9ccc17a%7C0%7C0%7C637612854914595696%7CUnknown%7C > > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX > > VCI6Mn0%3D%7C1000&sdata=%2FW6HuFPYQCD5ECIA%2FZZxhm5ti5HYILNlsWTz > > moJ7L8E%3D&reserved=0 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

3 years, 11 months

6
17
0 0

Re: [TF-A] PSCI lock contention

by Varun Wadekar

<Adding TF-A mailing list to the discussion> Thanks, Soby. I agree that this needs to be re-evaluated for platforms. I think we should introduce an option to disable them, if required. We plan to try some more experiments and hopefully remove the locks at least for Tegra platforms. Looking forward to the elaborate answer. From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: Tuesday, 2 November 2021 10:18 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; Manish Pandey2 <Manish.Pandey2(a)arm.com>; Dan Handley <Dan.Handley(a)arm.com> Cc: Joanna Farley <Joanna.Farley(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com> Subject: RE: PSCI lock contention External email: Use caution opening links or attachments Hi Varun, The short answer is that the locks are used to differentiate the last-CPU-to-suspend and similarly first-CPU-to-powerup at a given power domain level. Now, recent CPU features like DynamIQ means that we don't need to do this differentiation upto cluster level which TF-A hasn't optimized for yet AFAICS. I am happy to elaborate further , but could you please send the query to the TF-A mailing list as I would prefer this discussion to happen in the open if possible. Best Regards Soby Mathew From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Sent: 01 November 2021 20:14 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>>; Dan Handley <Dan.Handley(a)arm.com<mailto:Dan.Handley@arm.com>> Cc: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>; Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>> Subject: PSCI lock contention Hi, We were trying performance benchmarking for CPU_SUSPEND on Tegra platforms. We take all CPU cores to CPU_SUSPEND and then wake them up with IPI - all at once and in serial order. From the numbers, we see that the CPUs powering up later take more time than the first one. We have narrowed the most time consumed to the PSCI locks - documented at docs/perf/psci-performance-juno.rst. Can you please help me understand why these locks were added? As a quick experiment we tried the same benchmarking *without* the locks and the firmware does not blow up, but I would like to understand the impact from the analysis on Juno (docs/perf/psci-performance-juno.rst) Happy to hop on a call to discuss further. Thanks. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

3 years, 11 months

2
8
0 0

Re: [TF-A] Trusted Firmware-A v2.6 release activities in November

by Joanna Farley

TF-A Community, Just a reminder we are looking to freeze the tree for release activities starting Monday. Thanks Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Joanna Farley <Joanna.Farley(a)arm.com> Date: Monday, 1 November 2021 at 12:41 To: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Trusted Firmware-A v2.6 release activities in November TF-A Community, This is to notify that we are planning to target the Trusted Firmware-A 2.6 release during the fourth week of Nov 2021 as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.5 release. As part of this, a release candidate tag will be created and release activities will commence from 15th November 2021 across all TF-A repositories. Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any patches desired to make the 2.6 release are submitted in good time to be complete by 12th November 2021. Any major enhancement patches still open after that date will not be merged until after the release. This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Jobs. We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start. Thanks Joanna

3 years, 11 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Nov 4, 2021 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with this note: "No TF-A Tech Forum scheduled this week so cancelling." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this 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   When: Thu Nov 4, 2021 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * 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 courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 12 months

2
1
0 0

FW: Two issues in Qemu port docs

by Joanna Farley

Forwarded on to TF-A Mail list. Seems postings from people with gmail.com email domains get automatically rejected, sorry Ramon not sure if that can be addressed. Joanna On 03/11/2021, 14:20, "Ramon Fried" <rfried.dev(a)gmail.com> wrote: Hi. I'm trying to run the example in TF-A documentation. I found two problems. First, the files: "tee-header_v2.bin, tee-pager_v2.bin, tee-pageable_v2.bin" are not provided as binary downloads, and instructions on how to get them are missing. turn's out you need to build optee, but this step is skipped if you choose to download the QEMU_EFI.fd from Linaro. Second, after following the instructions step by step resulted in the following error: qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-a57 -kernel Image -no-acpi -append 'console=ttyAMA0,38400 keep_bootcon' -initrd rootfs.cpio.gz -smp 2 -m 1024 -bios flash.bin -d unimp NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.5(release):v2.5-60-g7737fdf0e NOTICE: BL1: Built : 13:12:39, Nov 3 2021 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.5(release):v2.5-60-g7737fdf0e NOTICE: BL2: Built : 13:12:42, Nov 3 2021 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.5(release):v2.5-60-g7737fdf0e NOTICE: BL31: Built : 13:12:45, Nov 3 2021 read access to unsupported AArch64 system register op0:3 op1:0 crn:12 crm:12 op2:4 This occurs on Qemu 5.0 and also 6.0 Thanks, Ramon.

3 years, 12 months

2
1
0 0

Trusted Firmware-A v2.6 release activities in November

by Joanna Farley

TF-A Community, This is to notify that we are planning to target the Trusted Firmware-A 2.6 release during the fourth week of Nov 2021 as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.5 release. As part of this, a release candidate tag will be created and release activities will commence from 15th November 2021 across all TF-A repositories. Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any patches desired to make the 2.6 release are submitted in good time to be complete by 12th November 2021. Any major enhancement patches still open after that date will not be merged until after the release. This will involve the various repositories making up the broader TF-A project including the TF-A mainline, TF-A Tests, Hafnium, TF-A CI Scripts and TF-A CI Jobs. We will endeavour minimise the disruption on patch merging and complete release activities ASAP after we start. Thanks Joanna

3 years, 12 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 373791: Control flow issues (DEADCODE) /drivers/usb/usb_device.c: 646 in usb_core_receive() ________________________________________________________________________________________________________ *** CID 373791: Control flow issues (DEADCODE) /drivers/usb/usb_device.c: 646 in usb_core_receive() 640 ep->is_in = false; 641 ep->num = num; 642 643 if (num == 0U) { 644 pdev->driver->ep0_start_xfer(hpcd->instance, ep); 645 } else { >>> CID 373791: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "(*pdev->driver->ep_start_xf...". 646 pdev->driver->ep_start_xfer(hpcd->instance, ep); 647 } 648 649 return USBD_OK; 650 } 651 ** CID 373790: Null pointer dereferences (FORWARD_NULL) /drivers/usb/usb_device.c: 182 in usb_core_set_config() ________________________________________________________________________________________________________ *** CID 373790: Null pointer dereferences (FORWARD_NULL) /drivers/usb/usb_device.c: 182 in usb_core_set_config() 176 } else if (cfgidx != pdev->dev_config) { 177 if (pdev->class != NULL) { 178 usb_core_ctl_error(pdev); 179 return; 180 } 181 /* Clear old configuration */ >>> CID 373790: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "pdev->class". 182 pdev->class->de_init(pdev, pdev->dev_config); 183 /* Set new configuration */ 184 pdev->dev_config = cfgidx; 185 /* Set configuration and start the USB class */ 186 if (pdev->class->init(pdev, cfgidx) != 0U) { 187 usb_core_ctl_error(pdev); ** CID 373789: Control flow issues (DEADCODE) /drivers/usb/usb_device.c: 684 in usb_core_transmit() ________________________________________________________________________________________________________ *** CID 373789: Control flow issues (DEADCODE) /drivers/usb/usb_device.c: 684 in usb_core_transmit() 678 ep->is_in = true; 679 ep->num = num; 680 681 if (num == 0U) { 682 pdev->driver->ep0_start_xfer(hpcd->instance, ep); 683 } else { >>> CID 373789: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "(*pdev->driver->ep_start_xf...". 684 pdev->driver->ep_start_xfer(hpcd->instance, ep); 685 } 686 687 return USBD_OK; 688 } 689 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 years, 12 months

1
0
0 0

ARM Trusted memory Resolution

by IS20 Boaz Baron

Hi all, What is the resolution for secure memory space with the Trust zone? Is it dependent on the MMU resolution? Means, for example, If my MMU can set a range of 16 KB so can I set that range as a trusted zone as well? P.S. I have ARM A35 (I am not sure but I think my MMU supports a resolution of 32KB) You are welcome to comment if I have any mistakes Thanks a lot, Boaz. ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

4 years

1
0
0 0

CFI in tf-a

by chen feng

I want to know if we have a chance to support the compiler-based CFI(eg clang cfi, kernel support it.) function in tf-a. I want to know that is anyone doing this, or if everyone is interested in this? Cheers, Feng

4 years

2
1
0 0

TF-A Tech Forum Agenda: Thu 21st October 2021 16:00 – 17:00 (BST)

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for 21st October 2021 16:00 – 17:00 (BST). Agenda: * Title: Realm Management Extension (RME) Granule Protection Table (GPT) Overview * Presented by: John Powell * Summary: Following on from the RME Overview session on 23rd September this session will provide more details of the Granule Protection Table (GPT) support recently upstreamed and the session will cover: 1. Overview of what GPT is 2. How it works 3. How it's configured and organized 4. Table initialization in TFA and why we do it this way 5. Runtime initialization and granule transition service ========================== If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. Thanks Joanna

4 years

1
0
0 0

Re: [TF-A] TFA affinity power level

by Madhukar Pappireddy

Hi HPChen 1. Can try setting PLATFORM_MAX_AFFLVL to MPIDR_AFFLVL2? I am assuming your platform has 1 cluster with 2 cores. 2. The project currently supports a limited number of platforms. The default test suite[1] contains several smaller test suites. The tests are designed to auto-detect critical features supported by the platform. Rather than fail, tftf will skip tests if a feature is not supported. Please refer to the documentation for the tf-a-tests project here: https://trustedfirmware-a-tests.readthedocs.io/en/latest/index.html [1] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/tests-s… Thanks, Madhukar -----Original Message----- From: TF-A <mailman-bounces(a)lists.trustedfirmware.org> On Behalf Of MS10 HPChen0 Sent: Tuesday, October 12, 2021 10:43 PM To: tf-a-owner(a)lists.trustedfirmware.org Subject: TFA affinity power level Hi, I'm Nuvoton software engineer. We have an A35 dual core platform. I ported the TFA for this platform. Now I want test the TFA on test suite. I have some questions. Please help to answer. Thanks! 1. If define 'PLATFORM_MAX_AFFLVL' to MPIDR_AFFLVL1. The tftf test only identify single core no matter 'PLATFORM_CORES_PER_CLUSTER' define to 2. How should I define 'PLATFORM_MAX_AFFLVL'? 2. How to select the test items? Should our platform need to pass all test items? Now I only test the tftf. I'm new for TFA. Please help. Thanks! Best regards, HPChen ________________________________ ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

4 years

1
0
0 0

Support for passing 18 parameters to/from an SMC call in AArch64

by Rebecca Cran

I noticed TF-A currently supports passing in 4 parameters and returning up to 8. But SMCCC 1.1+ supports passing up to 18 and returning 18 in AArch64 mode, and passing in/out 8 in AArch32. I was wondering if there are any plans to add support for handling the full set of parameters? -- Rebecca Cran

4 years

2
2
0 0

BL1 loading BL2 but returned file length 4294967295

by 起飞的老杨

Hi I'm new to TF-A and OP Tee. While I am using qemu to start TF-A, I got BL1 detected and failed to load BL2, due to BL2 size out of bounds. I changed TF-A BL1 source code to show more information: diff --git a/common/bl_common.c b/common/bl_common.c index 2fcb5385d9..a6239a5257 100644 --- a/common/bl_common.c +++ b/common/bl_common.c @@ -110,7 +111,7 @@ static int load_image(unsigned int image_id, image_info_t *image_data) /* Check that the image size to load is within limit */ if (image_size > image_data->image_max_size) { - WARN("Image id=%u size out of bounds\n", image_id); + WARN("Image id=%u size(%lu, %u) out of bounds\n", image_id, image_size, image_data->image_max_size); io_result = -EFBIG; goto exit; } the log shows: NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.3():v2.3-dirty NOTICE: BL1: Built : 15:56:43, Apr 20 2020 INFO: BL1: RAM 0xe04e000 - 0xe056000 VERBOSE: BL1: cortex_a57: CPU workaround for 806969 was not applied WARNING: BL1: cortex_a57: CPU workaround for 813419 was missing! VERBOSE: BL1: cortex_a57: CPU workaround for 813420 was not applied VERBOSE: BL1: cortex_a57: CPU workaround for 814670 was not applied WARNING: BL1: cortex_a57: CPU workaround for 817169 was missing! INFO: BL1: cortex_a57: CPU workaround for disable_ldnp_overread was applied WARNING: BL1: cortex_a57: CPU workaround for 826974 was missing! WARNING: BL1: cortex_a57: CPU workaround for 826977 was missing! WARNING: BL1: cortex_a57: CPU workaround for 828024 was missing! WARNING: BL1: cortex_a57: CPU workaround for 829520 was missing! WARNING: BL1: cortex_a57: CPU workaround for 833471 was missing! WARNING: BL1: cortex_a57: CPU workaround for 859972 was missing! INFO: BL1: cortex_a57: CPU workaround for cve_2017_5715 was applied INFO: BL1: cortex_a57: CPU workaround for cve_2018_3639 was applied INFO: BL1: Loading BL2 VERBOSE: Using Memmap WARNING: Firmware Image Package header check failed. VERBOSE: Trying alternative IO VERBOSE: Using Semi-hosting IO INFO: Loading image id=1 at address 0xe01b000 WARNING: Image id=1 size(4294967295, 151552) out of bounds ERROR: Failed to load BL2 firmware. I'm using yocto (dunfell) + meta-arm to build / test TF-A + OP TEE under qemuarm64. meta-arm rev: c4f04f3fb66f8f4365b08b553af8206372e90a63 variables defined inside conf/local.conf ( for test ) 23 MACHINE ?= "qemuarm64" 25 26 INSANE_SKIP_pn-optee-examples = "ldflags" 27 COMPATIBLE_MACHINE_pn-optee-examples = "qemuarm64" 28 COMPATIBLE_MACHINE_pn-optee-os = "qemuarm64" 29 COMPATIBLE_MACHINE_pn-optee-client = "qemuarm64" 30 COMPATIBLE_MACHINE_pn-trusted-firmware-a = "qemuarm64" 31 32 TFA_PLATFORM = "qemu" 33 TFA_UBOOT = "1" 34 TFA_DEBUG = "1" 35 TFA_SPD = "opteed" 36 TFA_BUILD_TARGET = "bl1 bl2 bl31" 37 38 OPTEEMACHINE:qemuarm64 = "vexpress-qemu_armv8a" 39 OPTEEOUTPUTMACHINE:qemuarm64 = "vexpress" 40 41 UBOOT_MACHINE_qemuarm64 = "qemu_arm64_defconfig" I started qemu using following command line: BIOS=tmp/deploy/images/qemuarm64/bl1.bin \ KERNEL=tmp/deploy/images/qemuarm64/Image-qemuarm64.bin \ runqemu mydefined-image-core-image-dev-optee nographic -d \ qemuparams=" \ -machine secure=on \ -m 4096 \ -d unimp -semihosting -semihosting-config enable=on,target=native \ " Thanks

4 years

3
2
0 0

[RFC]: UFS patches

by Jorge Troncoso

Hi all, We made a few changes to the UFS driver. The proposed patches are posted here: https://review.trustedfirmware.org/q/topic:%22ufs_patches%22+(status:open%2… . The patches mainly consist of the below changes: 1. Delete asserts. Return error values instead. 2. Add retry logic and timeouts. 3. Reuse ufshc_send_uic_cmd() for DME_GET and DME_SET commands. Any feedback/comments on these patches would be greatly appreciated. Thanks! Jorge Troncoso

4 years

5
11
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 4 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 5 of 5 defect(s) ** CID 373584: (BAD_SHIFT) /lib/gpt_rme/gpt_rme.c: 335 in gpt_validate_l0_params() /lib/gpt_rme/gpt_rme.c: 346 in gpt_validate_l0_params() ________________________________________________________________________________________________________ *** CID 373584: (BAD_SHIFT) /lib/gpt_rme/gpt_rme.c: 335 in gpt_validate_l0_params() 329 } 330 gpt_config.pps = pps; 331 gpt_config.t = gpt_t_lookup[pps]; 332 333 /* Alignment must be the greater of 4k or l0 table size. */ 334 l0_alignment = PAGE_SIZE_4KB; >>> CID 373584: (BAD_SHIFT) >>> In expression "0xffffffffffffffffUL >> 64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", right shifting by more than 63 bits has undefined behavior. The shift amount, "64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", is 64. 335 if (l0_alignment < GPT_L0_TABLE_SIZE(gpt_config.t)) { 336 l0_alignment = GPT_L0_TABLE_SIZE(gpt_config.t); 337 } 338 339 /* Check base address. */ 340 if ((l0_mem_base == 0U) || ((l0_mem_base & (l0_alignment - 1)) != 0U)) { /lib/gpt_rme/gpt_rme.c: 346 in gpt_validate_l0_params() 340 if ((l0_mem_base == 0U) || ((l0_mem_base & (l0_alignment - 1)) != 0U)) { 341 ERROR("[GPT] Invalid L0 base address: 0x%lx\n", l0_mem_base); 342 return -EFAULT; 343 } 344 345 /* Check size. */ >>> CID 373584: (BAD_SHIFT) >>> In expression "0xffffffffffffffffUL >> 64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", right shifting by more than 63 bits has undefined behavior. The shift amount, "64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", is 64. 346 if (l0_mem_size < GPT_L0_TABLE_SIZE(gpt_config.t)) { 347 ERROR("[GPT] Inadequate L0 memory: need 0x%lx, have 0x%lx)\n", 348 GPT_L0_TABLE_SIZE(gpt_config.t), 349 l0_mem_size); 350 return -ENOMEM; 351 } ** CID 373583: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 373583: Memory - corruptions (OVERRUN) /plat/imx/imx7/warp7/warp7_bl2_el3_setup.c: 110 in warp7_usdhc_setup() 104 105 zeromem(&params, sizeof(imx_usdhc_params_t)); 106 params.reg_base = PLAT_WARP7_BOOT_MMC_BASE; 107 params.clk_rate = 25000000; 108 params.bus_width = MMC_BUS_WIDTH_8; 109 mmc_info.mmc_dev_type = MMC_IS_EMMC; >>> CID 373583: Memory - corruptions (OVERRUN) >>> Overrunning struct type imx_usdhc_params_t of 16 bytes by passing it to a function which accesses it at byte offset 23. 110 imx_usdhc_init(&params, &mmc_info); 111 } 112 113 static void warp7_setup_usb_clocks(void) 114 { 115 uint32_t usb_en_bits = (uint32_t)USB_CLK_SELECT; ** CID 373582: Null pointer dereferences (NULL_RETURNS) /plat/intel/soc/common/socfpga_storage.c: 171 in socfpga_io_setup() ________________________________________________________________________________________________________ *** CID 373582: Null pointer dereferences (NULL_RETURNS) /plat/intel/soc/common/socfpga_storage.c: 171 in socfpga_io_setup() 165 166 result = io_dev_open(fip_dev_con, (uintptr_t)NULL, &fip_dev_handle); 167 assert(result == 0); 168 169 if (boot_source == BOOT_SOURCE_SDMMC) { 170 partition_init(GPT_IMAGE_ID); >>> CID 373582: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "get_partition_entry(a2)", which is known to be "NULL". 171 fip_spec.offset = get_partition_entry(a2)->start; 172 } 173 174 (void)result; 175 } 176 ** CID 373581: (BAD_SHIFT) /lib/gpt_rme/gpt_rme.c: 780 in gpt_init_l0_tables() /lib/gpt_rme/gpt_rme.c: 775 in gpt_init_l0_tables() ________________________________________________________________________________________________________ *** CID 373581: (BAD_SHIFT) /lib/gpt_rme/gpt_rme.c: 780 in gpt_init_l0_tables() 774 /* Iterate through all L0 entries */ 775 for (unsigned int i = 0U; i < GPT_L0_REGION_COUNT(gpt_config.t); i++) { 776 ((uint64_t *)l0_mem_base)[i] = gpt_desc; 777 } 778 779 /* Flush updated L0 tables to memory. */ >>> CID 373581: (BAD_SHIFT) >>> In expression "0xffffffffffffffffUL >> 64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", right shifting by more than 63 bits has undefined behavior. The shift amount, "64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", is 64. 780 flush_dcache_range((uintptr_t)l0_mem_base, 781 (size_t)GPT_L0_TABLE_SIZE(gpt_config.t)); 782 783 /* Stash the L0 base address once initial setup is complete. */ 784 gpt_config.plat_gpt_l0_base = l0_mem_base; 785 /lib/gpt_rme/gpt_rme.c: 775 in gpt_init_l0_tables() 769 } 770 771 /* Create the descriptor to initialize L0 entries with. */ 772 gpt_desc = GPT_L0_BLK_DESC(GPT_GPI_ANY); 773 774 /* Iterate through all L0 entries */ >>> CID 373581: (BAD_SHIFT) >>> In expression "0xffffffffffffffffUL >> 64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", right shifting by more than 63 bits has undefined behavior. The shift amount, "64U - ((gpt_config.t > (unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) ? gpt_config.t - ((unsigned int)((read_gpccr_el3() >> 20U) & 0xfUL) + 30U) : 0U)", is 64. 775 for (unsigned int i = 0U; i < GPT_L0_REGION_COUNT(gpt_config.t); i++) { 776 ((uint64_t *)l0_mem_base)[i] = gpt_desc; 777 } 778 779 /* Flush updated L0 tables to memory. */ 780 flush_dcache_range((uintptr_t)l0_mem_base, ** CID 373580: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 373580: Memory - corruptions (OVERRUN) /plat/imx/imx7/picopi/picopi_bl2_el3_setup.c: 104 in picopi_usdhc_setup() 98 99 zeromem(&params, sizeof(imx_usdhc_params_t)); 100 params.reg_base = PLAT_PICOPI_BOOT_MMC_BASE; 101 params.clk_rate = 25000000; 102 params.bus_width = MMC_BUS_WIDTH_8; 103 mmc_info.mmc_dev_type = MMC_IS_EMMC; >>> CID 373580: Memory - corruptions (OVERRUN) >>> Overrunning struct type imx_usdhc_params_t of 16 bytes by passing it to a function which accesses it at byte offset 23. 104 imx_usdhc_init(&params, &mmc_info); 105 } 106 107 static void picopi_setup_usb_clocks(void) 108 { 109 uint32_t usb_en_bits = (uint32_t)USB_CLK_SELECT; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years

1
0
0 0

Re: [TF-A] ATF F/w image Decryption support

by Sumit Garg

+ TF-A ML (for the benefit of other trying to use firmware encryption feature) Hi Promod, On Fri, 8 Oct 2021 at 00:09, pramod kumar <pramod.jnumca04(a)gmail.com> wrote: > Hi Sumit, > > This is Pramod, Presently working in Amazon Lab126. I'm working in ATF and > was going through your patch which provides f/w image encryption/decryption > support. > > commit 7cda17bb0f92db39d123a4f2a1732c9978556453 > Author: Sumit Garg <sumit.garg(a)linaro.org> > Date: Fri Nov 15 10:43:00 2019 +0530 > > drivers: crypto: Add authenticated decryption framework > > Add framework for autheticated decryption of data. Currently this > patch optionally imports mbedtls library as a backend if build option > "DECRYPTION_SUPPORT = aes_gcm" is set to perform authenticated > decryption > using AES-GCM algorithm. > > Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> > Change-Id: I2966f0e79033151012bf4ffc66f484cd949e7271 > > I see that this support comes under DECRYPTION_SUPPORT macro hence can't > be used dynamically. I see the TBBR spec provides a flag for this which > could be used to exercise this feature dynamically- > [image: image.png] > > > Just wanted to understand that did you see any limitation to use this flag > for making this feature support dynamically? Or do you have any plan to > push follow up patches for this? > > Actually there are security concerns associated if we use an unsigned encryption flag in the header (see earlier discussions [1]). > If this feature is made available, with the help of "disable_auth" flag, > BL1 would be able to boot plane images even when TRUSTED_BOARD_BOOT is > enabled in development mode. > I agree here that it would be useful to have such a flag in development mode. For TRUSTED_BOARD_BOOT in development mode, I guess you are referring to DYN_DISABLE_AUTH. If yes then I think such a macro makes sense for encryption as well in order to disable decryption at runtime in development mode, patches are very much welcome. [1] https://lists.trustedfirmware.org/pipermail/tf-a/2020-February/000288.html -Sumit > Regards, > Pramod >

4 years

1
0
0 0

[RFC]: Refactor measured boot patches

by Manish Badarkhe

Hi All, We have refactored/redesigned the existing measured boot driver present in the TF-A repo to support it with multiple backend driver(s) (for example, TCG Event Log, physical TPM, etc) instead of it being strongly coupled with the TCG Event Log driver. Proposed refactored patches are posted here: https://review.trustedfirmware.org/q/topic:%22refactor-mb%22+(status:open%2… Any feedback/comments on these patches are much appreciated. These patches mainly consist of the below changes: 1. Move image measurement in the generic layer, just after loading and authentication of the image. Previously, the platform layer was responsible for the measurement. For example, the Arm FVP platform layer was doing it as part of the post-load hook operation. 2. Measurement and recording of the images loaded by BL1. Previously, DTB config files loaded by BL1 were not part of measured at all. Also, it looks safer and cleaner approach to record the measurement taken by BL1 straightaway in TCG Event log buffer/physical TPM/any other TPM backend instead of deferring these recordings to BL2. 3. Pass Event Log buffer information from BL1 to BL2 so that the TCG Event Log buffer initialised by BL1 extended further with the measurements taken by BL2. Note: These patches neither add any new functional backend driver for measured boot nor update any existing backend driver functionality (i.e. TCG Event Log driver). These changes only structured the measured boot code to provide a space to plug in any new backend driver(s) in future for the measured boot. Thanks, Manish Badarkhe

4 years

2
1
0 0

Canceled event with note: TF-A Tech Forum @ Thu Oct 7, 2021 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with this note: "Cancelling this weeks TF-A Tech Forum as we have no subjects/topics to present for this meeting. The TF-A project community is always looking for subjects/topics so if you have something to present/discuss please do reach out to me and we can schedule a session. Thanks all." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this 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   When: Thu Oct 7, 2021 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * 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 courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years

1
0
0 0

Issue submitting changes for review at https://review.trustedfirmware.org

by Jorge Troncoso

Hi all, I tried submitting a change for review at https://review.trustedfirmware.org, but I ran into authentication issues. 1. First try (https): $ git push origin HEAD:refs/for/integration Username for 'https://review.trustedfirmware.org': jatron Password for 'https://jatron@review.trustedfirmware.org': remote: Unauthorized fatal: Authentication failed for ' https://review.trustedfirmware.org/TF-A/trusted-firmware-a/' I tried clicking "GENERATE NEW PASSWORD" in https://review.trustedfirmware.org/settings/, but I got the following error message: An error occurred Error 500 (Server Error): Internal server error Endpoint: /accounts/self/password.http 2. Second try (ssh): I got the following error message when I tried registering a new SSH key for use with Gerrit. This happened when I clicked "ADD NEW SSH KEY" in https://review.trustedfirmware.org/settings/. An error occurred Error 500 (Server Error): Internal server error Endpoint: /accounts/self/sshkeys The error message didn't stop the GUI from recording my key though. My new key was listed under "SSH keys" after the change. When I ran a git push command using ssh, I got the following error. $ git push ssh://jatron@review.trustedfirmware.org/TF-A/trusted-firmware-a HEAD:refs/for/integration jatron(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. Am I doing something incorrectly? Any help would be much appreciated. If this is not the mailing list for these types of questions, please let me know so I can reroute my email to the proper destination. Thanks, Jorge Troncoso

4 years, 1 month

2
3
0 0

: Forthcoming UFS driver patches

by Jorge Troncoso

Hi all, I'm planning to submit a series of patches that aim to improve the robustness and reusability of the UFS code. The impacted files are drivers/ufs/ufs.c and include/drivers/ufs.h. The patches mainly consist of the below changes: 1. Delete asserts. Return error values instead. 2. Add retry logic and timeouts. 3. Remove infinite loops. 4. Reuse ufshc_send_uic_cmd() for DME_GET and DME_SET commands. 5. Add a function ufs_send_cmd() that can be reused in other places. ufs_send_cmd() calls four functions in sequence: get_utrd(&utrd), ufs_prepare_cmd(&utrd, ...), ufs_send_request(utrd.task_tag), and ufs_check_resp(&utrd, RESPONSE_UPIU). I wanted to give everyone visibility of what is coming up and hopefully start a discussion around this work. Any early input to help shape the design would be much appreciated. Thanks, Jorge Troncoso

4 years, 1 month

1
0
0 0

How to write a Trsuted Application?

by Chenxu Wang

Hi all, I want to write a TA which will be called from the Normal World and be handled by a specific Trusted OS. Currently, I am using 3 Cactus OS (provided by TF-A-Tests) in SEL1, and a Hafnium in SEL2. Here is my partial building cmd make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1 ARM_ARCH_MINOR=4 PLAT=fvp DEBUG=1 BL33=../tf-a-tests/build/fvp/debug/tftf.bin BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin SP_LAYOUT_FILE=../tf-a-tests/build/fvp/debug/sp_layout.json all fip I have created some EL3 services at services/std_svc, but have not created a TA. In my view, to call the TA, I think I should pass (1) the ID of the TA (but I am not sure how to get the ID) (2) several parameters, which may be loaded into registers. Here may be a calling process. ldr x0,=0xdeadbeef // loading ID ldr x1,=0x11111 // input parameters ldr x2,=0x22222 // input parameters smc #0 Then I think I should write a corresponding handler (of the TA) in Cactus OS. When we call "smc #0", EL3 will trap it, and route it to a specific TA. However, I don't know how to do it. Can you provide some useful examples? Sincerely, Wang Chenxu

4 years, 1 month

3
4
0 0

TF-A Tech Forum Agenda: Thu 23rd September 2021 16:00 – 17:00 (BST)

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for 23rd September 2021 16:00 – 17:00 (BST). Agenda: * Title: Realm Management Extension (RME) Support in TF-A * Presented by: Zelalem Aweke * Summary: RME is an Armv9-A extension and is one component of the Arm Confidential Compute Architecture (Arm CCA). In this talk I will give a brief introduction to Arm CCA and RME. Then I will talk about the changes in TF-A to support RME that are expected to be part of the TF-A v2.6 release. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. Thanks Joanna

4 years, 1 month

1
0
0 0

Issue with @foss.st.com e-mail address

by Yann Gautier

Hello, Last Thursday we got an issue on our @foss.st.com mail server, preventing us from receiving mails. The issue was corrected, and I can now correctly receive mails, except the ones from trustedfirmware.org. Is there some kind of filtering on trustedfirmware.org side, as those addresses got error replies? I've tried to delete my yann.gautier(a)foss.st.com in the trusted firmware gerrit settings, to re-enter it again, but I cannot receive the verification e-mail. Could you check if @foss.st.com addresses are rejected somewhere? Thanks, Yann

4 years, 1 month

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 373165: Code maintainability issues (UNUSED_VALUE) /plat/mediatek/mt8195/drivers/spm/mt_spm_vcorefs.c: 467 in spm_vcorefs_get_vcore() ________________________________________________________________________________________________________ *** CID 373165: Code maintainability issues (UNUSED_VALUE) /plat/mediatek/mt8195/drivers/spm/mt_spm_vcorefs.c: 467 in spm_vcorefs_get_vcore() 461 int spm_vcorefs_get_vcore(unsigned int gear) 462 { 463 int ret_val; 464 465 switch (gear) { 466 case 3: >>> CID 373165: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "vcore_opp_0_uv" to "ret_val" here, but that stored value is overwritten before it can be used. 467 ret_val = vcore_opp_0_uv; 468 case 2: 469 ret_val = vcore_opp_1_uv; 470 case 1: 471 ret_val = vcore_opp_2_uv; 472 case 0: ** CID 373164: Code maintainability issues (UNUSED_VALUE) /plat/mediatek/mt8195/drivers/spm/mt_spm_vcorefs.c: 471 in spm_vcorefs_get_vcore() ________________________________________________________________________________________________________ *** CID 373164: Code maintainability issues (UNUSED_VALUE) /plat/mediatek/mt8195/drivers/spm/mt_spm_vcorefs.c: 471 in spm_vcorefs_get_vcore() 465 switch (gear) { 466 case 3: 467 ret_val = vcore_opp_0_uv; 468 case 2: 469 ret_val = vcore_opp_1_uv; 470 case 1: >>> CID 373164: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "vcore_opp_2_uv" to "ret_val" here, but that stored value is overwritten before it can be used. 471 ret_val = vcore_opp_2_uv; 472 case 0: 473 default: 474 ret_val = vcore_opp_3_uv; 475 } 476 return ret_val; ** CID 373163: Code maintainability issues (UNUSED_VALUE) /plat/mediatek/mt8195/drivers/spm/mt_spm_vcorefs.c: 469 in spm_vcorefs_get_vcore() ________________________________________________________________________________________________________ *** CID 373163: Code maintainability issues (UNUSED_VALUE) /plat/mediatek/mt8195/drivers/spm/mt_spm_vcorefs.c: 469 in spm_vcorefs_get_vcore() 463 int ret_val; 464 465 switch (gear) { 466 case 3: 467 ret_val = vcore_opp_0_uv; 468 case 2: >>> CID 373163: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "vcore_opp_1_uv" to "ret_val" here, but that stored value is overwritten before it can be used. 469 ret_val = vcore_opp_1_uv; 470 case 1: 471 ret_val = vcore_opp_2_uv; 472 case 0: 473 default: 474 ret_val = vcore_opp_3_uv; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 1 month

1
0
0 0

Disable the EL2 hypervisor mode

by IS20 Boaz Baron

Hi all, I have a little question, how can I disable the hypervisor mode so EL2 will be just bridge to EL1 ns? (I mean without touching common ARM code only the platform-oriented code) Thanks, Boaz. ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

4 years, 1 month

2
1
0 0

Canceled event with note: TF-A Tech Forum @ Thu Sep 9, 2021 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with this note: "No subjects to present this week so cancelling." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this 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   When: Thu Sep 9, 2021 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * 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 courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 1 month

1
0
0 0

include/plat/common in project path?

by Yann Gautier

Hi, When I check the tf-static-checks for the FIP/FCONF series I pushed for STM32MP1, I have a failure: 1d204ee4a:plat/st/common/bl2_io_storage.c: ['tools_share/firmware_image_package.h should be in project group, after system group'] First I didn't understand the issue, as the file is in project group. But the issue is due to previous include: #include <plat/common/platform.h> As it is inside include/plat directory, it is seen as a platform include. For me the files in this include/plat/common directory are more project, but what is your point of view? If they are platform files, I should modify my series to reflect that. If they are project files, then the check-include-order.py script should be updated. Here is what could be the correction: diff --git a/script/static-checks/check-include-order.py b/script/static-checks/check-include-order.py index aaf84f1..53d355b 100755 --- a/script/static-checks/check-include-order.py +++ b/script/static-checks/check-include-order.py @@ -87,6 +87,8 @@ def inc_order_is_correct(inc_list, path, commit_hash=""): incs = collections.defaultdict(list) error_msgs = [] plat_incs = dir_include_paths("plat") | dir_include_paths("include/plat") + plat_common_incs = dir_include_paths("include/plat/common") + plat_incs.difference_update(plat_common_incs) libc_incs = dir_include_paths("include/lib/libc") Best regards, Yann

4 years, 1 month

1
0
0 0

Re: [TF-A] Secure boot without FIP

by Yann Gautier

On 7/28/21 10:50 AM, guillaume pivetta via TF-A wrote: > Hi, I’m trying to implement a secure boot on a STM32MP1 without using > the FIP file. > Hi Guillaume, Sorry for this very late reply. > For now , I am not able to use FIP format during the boot process so I > use a depreciated boot process with TF-Av2.2 as FSBL and U-Boot as SSBL > to boot my Board. > That's quite an old software. If you can, I'd suggest you update the software to the version delivered by ST, based on a v2.4 label. The sources are available there: https://github.com/STMicroelectronics/arm-trusted-firmware And you should take the v2.4-stm32mp branch. In this software, FIP is available, and with a better support for TUSTED_BOARD_BOOT. > My boot process do Romcode -> TF-A (BL2) -> SP_min (BL32) -> U-Boot > (BL33) -> Linux kernel > > I succefully implemented signature authentification between U-Boot and > Linux image, but between TF-A and U-Boot it’s a little bit harder. > > I learned on ST wiki how to sign my u-boot binary with the > STM32MP_SigningTool_CLI, but when I sign my binary with a custom private > key, TF-A don’t authentified it on boot, even if i tryed to pass my key > to TF-A at compilation time with the BL33_KEY argument, which i think is > dedicated to the FIP usage. > > I found, in the sources of TF-A, what I think being a developpement key, > named « arm_rotpk_ecdsa.pem ». > > And when I sign my binary with this key, I am able to perform the > signature check and continu my boot process. So I tryed to change this > key with a custom one and recompile TF-A to update the key in the final > binary, but it seem that it is not so simple. > > I found yesterday that the auth_mod_init() function wasn’t call because > I had forgotten the TUSTED_BOARD_BOOT=1 compilation argument. But when I > activate it, the compilation doesn’t work and i see > > « build/arm-trusted-firmware-v2.2/bl2/bl2_main.c:91: undefined reference > to `auth_mod_init' » > > Whitch traditionnaly append when linker don’t find the .o where the > functions are implemented. > > I would like to know if it is possible to implement some kind of > authentification with custom keys without FIP and if yes where can i > find some hints/ressources/tutorial ? > > I don’t find a lot of ressources about secure boot without FIP so I hope > you will be able to help me. > > If you can switch to a newer software with FIP, you can check: https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FIP Else, the page that could help you is there: https://wiki.st.com/stm32mpu-ecosystem-v2/wiki/STM32MP15_secure_boot If you need more help, the better is to use the links given at the bottom of the wiki pages: ST Support Center (https://community.st.com/s/onlinesupport) or ST Community MPU Forum (https://community.st.com/s/topic/0TO0X0000003u2AWAQ/stm32-mpus). Best regards, Yann

4 years, 2 months

1
0
0 0

Canceled event with note: TF-A Tech Forum @ Thu Aug 26, 2021 4pm - 5pm (BST) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been canceled with this note: "Cancelling TF-A Tech forum this week as we have no scheduled topic." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this 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   When: Thu Aug 26, 2021 4pm – 5pm United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher - creator * 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 courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 2 months

1
0
0 0

Re: [TF-A] Rethrow SError from EL3 to kernel on arm64

by Ming Huang

Hi, I did the test report SDEI to kernel with fatal severity in APEI / CPER while EL3 received SEA(SCR_EL3.EA = 1). Kernel will panic and print calltrace, but this calltrace was not the position where error occured(another word where throw SEA), instead calltrace in ghes.c. How can SDEI solution let kernel print calltrace at right position? For issue analysis, the right position calltrace is very useful. For ACPI firmware-first, we set SCR_EL3.EA = 1, although the solution rethrow EA back to kernel will suffer from some problems, but this solution can let kernel print calltrace at right position. Best Regards, Ming Huang On 5/25/21 8:08 PM, James Morse via TF-A wrote: > Hi Pali, > > I assume the aborts you are ignoring are precise! SError can be imprecise. > I guess these are due to some integration issue with the PCIe root-complex. You shouldn't > get aborts outside a RAS error. PCIe has DPC/eDPC and AER for signalling RAS errors - I > guess these aren't supported on your platform. > > > To emulte the synchronous/asynchronous exceptions means emulating what the CPU would do if > SCR_EL3.EA weren't set. I'm not sure how familiar you are with the CPU's exception model > and all its routing/masking controls. A short tour of what is involved: > (the numbered references are for DDI0487G.a, they may have moved in your version) > > > To emulate an exception you need to copy ESR_EL3, SPSR_EL3 and ELR_EL3 to the ESR, SPSR > and ELR of the target EL. You need to calculated new PSTATE and PC for SPSR_EL3 and > ELR_EL3. The way the CPU does this is described in the psuedocode in the arm-arm. See > AArch64.TakeException. This will involve reading SCTLR of the target EL. > For Synchronous-External-Abort, if the FnV bit is clear, you should copy FAR_EL3 to FAR of > the target EL too. > > There is a GPL implementation of some of these bits in the kernel's KVM code, but that is > probably of limited use due to the license. > > > To determine the target EL you need to examine the routing controls set by the lower ELs. > Synchronous Exceptions are the easiest as they can't be masked: > The routing rules are describe in D1.12.4 "Routing synchronous External Aborts" is a > little terse. It glosses over HCR_EL2.TGE that would also route the exception to EL2. > > For a synchronous-external-abort triggered by EL1 where HCR_EL2.TERR is not supported, or > clear: If the fault was at stage1, it goes to EL1, if the fault was at stage2, it goes to > EL2. There is nothing the ESR to tell you which it was as the CPU indicates this with the > target EL, which was overridden by SCR_EL3.EA. (The architecture doesn't expect you to be > re-injecting exceptions from EL3). > Pragmatically the best option is to allow HCR_EL2.AMO to route synchronous exceptions to > EL2 too. (this is a big hint that a hypervisor is managing errors for this exception > level). If ELR_EL3.S1PTW is set, this is definitely a stage2 fault, EL1 should never see > this bit set. > (Synchronous Exceptions can't be routed to a lower EL). > > > Synchronous errors were the easy one. Asynchronous error routing is described in D1.13.1 > "Asynchronous exception routing". You want to take note of HCR_EL2.{AMO, TGE}. But it can > also be masked by PSTATE.A of the target EL. (See D1.13.2 "Asynchronous exception masking"): > If SPSR_EL3.M is the target EL, SPSR_EL3.A would have masked SError. You cannot emulate > the exception if this bit is set. > If SPSR_EL3.M is lower than the target EL, then you can emulate the exception to the > target EL. > If SPSR_EL3.M is higher than the target EL, then SError is effectively masked, and you > cannot emulate the exception. > > > (I don't think HPFAR_EL2 needs to be set for these cases, but I'd need to check) > > > Finally, you still need something to do if you can't emulate the exception. Updating a > system log if you have one and rebooting is the only real option. > > > > Thanks, > > James > > > On 25/05/2021 11:08, Pali Rohár wrote: >> Hello! >> >> Platform is not ACPI based. PCIe core in some cases sends External >> Aborts to kernel which needs to be masked/ignored. I have not found a >> way how to reconfigure PCIE core to not send these aborts. >> >> In mentioned review is a link to kernel list where was discussion about >> custom kernel handlers to ignore some of EA. But this approach was >> rejected with information that TF-A should handle these aborts and >> ignores those which should not be propagated back to kernel. >> >> If I clear SCR_EL3.EA then aborts (including those which should be >> ignored) are sent to kernel and kernel makes them fatal. So this is not >> a solution. >> >> If I do not clear SCR_EL3.EA then in TF-A board/platform code I can >> implement check for aborts which needs to be ignored. But remaining >> aborts are not delivered to kernel and TF-A makes them fatal. Which is >> not correct too. >> >> So, what I need, is to route all External Aborts to TF-A, implement >> logic which ignores specific PCIE aborts and all remaining aborts needs >> to be propagated back to kernel like if SCR_EL3.EA is clear. >> >> So it means to implement some logic of abort injection. >> >> On Tuesday 25 May 2021 11:00:09 James Morse wrote: >>> Hi Guys, >>> >>> Does this platform need external-aborts to be routed to EL3? If not, you can clear >>> SCR_EL3.EA and be done with it. This allows the EL2 OS/Hypervisor to take control of the >>> routing of these exceptions. (which sounds like what you want) >>> >>> >>> Otherwise: >>> As Soby describes, the choices are SDEI or emulate the exception according to the arm-arm >>> psuedocode as if EL3 weren't implemented. This is best avoided as its difficult to get >>> right: you have to create a new PSTATE for the target exception level, and read the >>> routing controls to work out which exception level that is. >>> >>> As Achin says, emulating the exception isn't always possible as Asynchronous exceptions >>> can be masked. The hardware does this automatically when it takes an exception (e.g. irq). >>> (Linux unmask it again once its read the CPU state). >>> >>> This can leave you holding what may be an imprecise-asynchronous-abort in EL3, unable to >>> emulate the exception or proceed without causing any RAS error to become uncontained. >>> If you can't inject the emulated exception, the error still has to be handled at EL3. If >>> this is an ACPI system you can do a soft restart of the normal-world and present the error >>> via ACPI's BERT (boot error record table) which describes an error that happened in a >>> previous life. >>> >>> >>> If your platform is ACPI firmware-first, using SDEI will make life easier. You still need >>> to handle the 'SDEI masked' case, but it is a lot less likely to happen. Linux only does >>> this over power-management events that (may) disable the MMU. >>> >>> >>> (EL2 doesn't have any of these problems as errors are almost always contained by stage2, >>> and it has hardware features for injecting asynchronous exceptions, which cope with the >>> masking and deferring) >>> >>> >>> Thanks, >>> >>> James >>> >>> >>> On 25/05/2021 10:08, Achin Gupta wrote: >>>> Hi, >>>> >>>> The last time I checked injecting an SError from a higher to lower EL is a bad >>>> idea since the latter could be running with SErrors masked. >>>> >>>> EL3 could check this before injecting but then there is no consistent contract >>>> with the lower EL about reporting of these errors. SDEI does not suffer from the >>>> same problem. >>>> >>>> +James who knows more from the OS/Hypervisor perspective. >>>> >>>> cheers, >>>> Achin >>>> -------------------------------------------------------------------------------- >>>> *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew >>>> via TF-A <tf-a(a)lists.trustedfirmware.org> >>>> *Sent:* 25 May 2021 09:59 >>>> *To:* Pali Rohár <pali(a)kernel.org> >>>> *Cc:* kabel(a)kernel.org <kabel(a)kernel.org>; tf-a(a)lists.trustedfirmware.org >>>> <tf-a(a)lists.trustedfirmware.org> >>>> *Subject:* Re: [TF-A] Rethrow SError from EL3 to kernel on arm64 >>>> [+tf-a list] >>>> Hi Pali, >>>> There are 2 philosophies for handing SError in the system, kernel first and >>>> firmware first. Assuming you want to stick with firmware first handling (i.e >>>> scr_el3.ea is set to 1), then as you mentioned, there are 2 ways to notify the >>>> kernel for delegating the error handling: SDEI and SError injection back to >>>> kernel. Upstream TF-A only supports SDEI at the moment. >>>> >>>> For SError injection back to lower EL, you have to setup the hardware state via >>>> software at higher EL in such a way that it appears that the fault was taken to >>>> the exception vector at the lower exception level. The pseudocode function >>>> AArch64.TakeException() in ARM ARM shows the behavior when the PE takes an >>>> exception to an Exception level using AArch64 in Non-debug state. This behaviour >>>> has to replicated and it involves the higher EL setting up the PSTATE registers >>>> correctly and values in other registers for the lower EL (spsr, elr and fault >>>> syndrome registers) and jumping to the right offset point to by the vbar_elx of >>>> the lower EL. To the lower EL is appears as a SError has triggered at its >>>> exception vector and it can proceed with the fault handling. >>>> >>>> Best Regards >>>> Soby Mathew >>>> >>>>> -----Original Message----- >>>>> From: Pali Rohár <pali(a)kernel.org> >>>>> Sent: Monday, May 24, 2021 6:07 PM >>>>> To: Soby Mathew <Soby.Mathew(a)arm.com> >>>>> Subject: Rethrow SError from EL3 to kernel on arm64 >>>>> >>>>> Hello Soby! >>>>> >>>>> I have found following discussion in Armada 3720 PCIe SError issue: >>>>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware- >>>> <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-> >>>>> a/+/1541/comment/ca882427_d142bde2/ >>>>> >>>>> TF-A on Armada 3720 redirects all SErrors to EL3 and panic in TF-A handler. >>>>> You wrote in that discussion: >>>>> >>>>> Ideally you need to signal the SError back to kernel from EL3 using >>>>> SDEI or inject the SError to the lower EL and the kernel can decide to >>>>> die or not. >>>>> >>>>> And I would like to ask you, could you help me with implementation of this >>>>> SError rethrow functionality? Because I have absolutely no idea how to do it >>>>> and catching all SErrors in EL3 is causing issues because some of them can be >>>>> handled and recovered by kernel. >>>> -- >>>> TF-A mailing list >>>> TF-A(a)lists.trustedfirmware.org >>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >>>> <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> >>>> >>> >

4 years, 2 months

2
6
0 0

[RFC] Realm Management Extension (RME) patches

by Zelalem Aweke

Hi All, We have upstreamed TF-A patches for Arm Realm Management Extension (RME) feature at: https://review.trustedfirmware.org/q/topic:%22za%252Ffeat_rme%22+(status:op…. Any reviews/comments are very much appreciated 🙂 RME is an Armv9-A extension and is one component of the Arm Confidential Compute Architecture (Arm CCA)<https://www.arm.com/why-arm/architecture/security-features/arm-confidential…>. The major changes with this extension include: * Two additional Security states, Root and Realm * Two additional physical address spaces, Root and Realm * The ability to dynamically transition memory granules between physical addresses spaces * Granule Protection Check mechanism More information about RME and Arm CCA can be found at [1] and [2]. [1] https://developer.arm.com/documentation/ddi0615/latest [2] https://developer.arm.com/documentation/den0125/latest Thanks, Zelalem

4 years, 2 months

1
0
0 0

TF-A Tech Forum Agenda: Thu 12th August 2021 16:00 – 17:00 (BST)

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 12th August 2021 16:00 – 17:00 (BST). Agenda: * Enabling S-EL0 FF-A partitions on Hafnium using ARMv8.1 FEAT_VHE – Presented by Raghupathy Krishnamurthy * Summary: Present and discuss enabling S-EL0 FF-A partitions on Hafnium using ARMv8.1 FEAT_VHE. The goal is to present an ARM server centric view point on the requirements in Secure World, the solution space explored to meet these requirements and why/how FF-A S-EL0 partition on hafnium using FEAT_VHE appear to fit these requirements. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. Thanks Joanna

4 years, 2 months

1
0
0 0

Re: [TF-A] TRNG SMCs intercepted by SPM-MM

by Olivier Deprez

Hi Andrew, I have submitted the change as you have passed it through the ML as a base for the discussion. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/11002 The issue is acknowledged, we had a brief discussion internally as to how best to refactor if need be. It looks to us the main problem is that SPM-MM (pre-dating FF-A) has aged a bit and mixes standard and impdef func ids. e.g. MM is an Arm standard and only defines two func ids (0x84000040, 0x84000041) so it may just be a matter of updating SPM_MM_FID_MAX_VALUE to 0x41 such that MM related services go through. The other ids 0xX4000060, 61, 64, 65 are purely impdef for the SPM-MM to/from SP communication. Thus we may define SP_MM_FID_MIN_VALUE/SP_MM_FID_MAX_VALUE and a corresponding is_sp_mm_fid macro. This would avoid the clash with TRNG IDs (0xX4000050, 51, 52, 53). What do you reckon? Btw out of curiosity how did you discover this? Do you have a setup enabling both SPM_MM and TRNG_SUPPORT option? Or maybe this is because of Trusty SPD reuse of spm_mm_smc_handler? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Andrew Scull via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 04 August 2021 22:50 To: Manish Pandey2 Cc: tf-a(a)lists.trustedfirmware.org; Jimmy Brisson; Andre Przywara Subject: Re: [TF-A] TRNG SMCs intercepted by SPM-MM I'm seeing server errors when I try "Generate Password" or setting the ssh key so I'm not sure how to push and authenticate. I've sent the patch directly to you, Manish, so the formatting doesn't get messed up and I don't know how to make git-send-email add it to a thread nicely.. On Wed, 4 Aug 2021 at 05:51, Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>> wrote: Hi Andrew, Thanks for reporting the bug, "DEN0060A_ARM_MM_Interface_Specification.pdf" does not talk about range for SPM_MM but don't know how it's mentioned in the comments. Will you be able to push a patch following instructions at https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm… 5. Contributor’s Guide — Trusted Firmware-A documentation<https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm…> 5. Contributor’s Guide¶ 5.1. Getting Started¶. Make sure you have a Github account and you are logged on both developer.trustedfirmware.org<http://developer.trustedfirmware.org> and review.trustedfirmware.org<http://review.trustedfirmware.org>. If you plan to contribute a major piece of work, it is usually a good idea to start a discussion around it on the mailing list. trustedfirmware-a.readthedocs.io<http://trustedfirmware-a.readthedocs.io> Repository: https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a , you will be able to login to gerrit using github credentials. TF-A/trusted-firmware-a · Gerrit Code Review<https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a> Gerrit Code Review review.trustedfirmware.org<http://review.trustedfirmware.org> If not, then could you please send me the patch file (it appears copying directly from email generates corrupt patch file) Thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Andrew Scull via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Sent: 03 August 2021 22:32 To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Cc: Andre Przywara <Andre.Przywara(a)arm.com<mailto:Andre.Przywara@arm.com>>; Jimmy Brisson <Jimmy.Brisson(a)arm.com<mailto:Jimmy.Brisson@arm.com>> Subject: [TF-A] TRNG SMCs intercepted by SPM-MM I've failed to figure out how to upload a CL so I'm resorting to this, it's more of a bug report anyway. There seems to be a conflict in how the standard SMCs are claimed with the TRNG SMCs claimed by SPM-MM before TRNG would get a chance to handle them properly. The patch below might fix the issue but I've not tested it or even built against ToT. ---- The TRNG SMCs use 0x84000050 to 0x84000053 which is in the range that SPM-MM claims for itself. Resolve this conflict by making SMC-MM much more selective about the SMCs it claims for itself. Signed-off-by: Andrew Scull <ascull(a)google.com<mailto:ascull@google.com>> Change-Id: If86b0d6a22497d34315c61fe72645b642c6e35f3 --- include/services/spm_mm_svc.h | 12 ++---------- services/std_svc/spm_mm/spm_mm_main.c | 12 ++++++++++++ 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/include/services/spm_mm_svc.h b/include/services/spm_mm_svc.h index 3148beb80..4247c95a1 100644 --- a/include/services/spm_mm_svc.h +++ b/include/services/spm_mm_svc.h @@ -38,17 +38,8 @@ #define SPM_MM_VERSION_COMPILED SPM_MM_VERSION_FORM(SPM_MM_VERSION_MAJOR, \ SPM_MM_VERSION_MINOR) -/* These macros are used to identify SPM-MM calls using the SMC function ID */ -#define SPM_MM_FID_MASK U(0xffff) -#define SPM_MM_FID_MIN_VALUE U(0x40) -#define SPM_MM_FID_MAX_VALUE U(0x7f) -#define is_spm_mm_fid(_fid) \ - ((((_fid) & SPM_MM_FID_MASK) >= SPM_MM_FID_MIN_VALUE) && \ - (((_fid) & SPM_MM_FID_MASK) <= SPM_MM_FID_MAX_VALUE)) - /* * SMC IDs defined in [1] for accessing MM services from the Non-secure world. - * These FIDs occupy the range 0x40 - 0x5f. * [1] DEN0060A_ARM_MM_Interface_Specification.pdf */ #define MM_VERSION_AARCH32 U(0x84000040) @@ -59,7 +50,6 @@ * SMC IDs defined for accessing services implemented by the Secure Partition * Manager from the Secure Partition(s). These services enable a partition to * handle delegated events and request privileged operations from the manager. - * They occupy the range 0x60-0x7f. */ #define SPM_MM_VERSION_AARCH32 U(0x84000060) #define MM_SP_EVENT_COMPLETE_AARCH64 U(0xC4000061) @@ -94,6 +84,8 @@ int32_t spm_mm_setup(void); +bool is_spm_mm_fid(uint32_t smc_fid); + uint64_t spm_mm_smc_handler(uint32_t smc_fid, uint64_t x1, uint64_t x2, diff --git a/services/std_svc/spm_mm/spm_mm_main.c b/services/std_svc/spm_mm/spm_mm_main.c index 14c0038ba..07226b0fb 100644 --- a/services/std_svc/spm_mm/spm_mm_main.c +++ b/services/std_svc/spm_mm/spm_mm_main.c @@ -266,6 +266,18 @@ static uint64_t mm_communicate(uint32_t smc_fid, uint64_t mm_cookie, SMC_RET1(handle, rc); } +/* Predicate indicating that a function id is part of SPM-MM */ +bool is_spm_mm_fid(uint32_t smc_fid) +{ + return ((smc_fid == MM_VERSION_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH64) || + (smc_fid == SPM_MM_VERSION_AARCH32) || + (smc_fid == MM_SP_EVENT_COMPLETE_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_GET_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_SET_AARCH64)); +} + /******************************************************************************* * Secure Partition Manager SMC handler. ******************************************************************************/ -- 2.32.0.554.ge1b32706d8-goog -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 2 months

2
2
0 0

Re: [TF-A] TRNG SMCs intercepted by SPM-MM

by Manish Pandey2

Hi Andrew, Thanks for reporting the bug, "DEN0060A_ARM_MM_Interface_Specification.pdf" does not talk about range for SPM_MM but don't know how it's mentioned in the comments. Will you be able to push a patch following instructions at https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm… 5. Contributor’s Guide — Trusted Firmware-A documentation<https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm…> 5. Contributor’s Guide¶ 5.1. Getting Started¶. Make sure you have a Github account and you are logged on both developer.trustedfirmware.org and review.trustedfirmware.org. If you plan to contribute a major piece of work, it is usually a good idea to start a discussion around it on the mailing list. trustedfirmware-a.readthedocs.io Repository: https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a , you will be able to login to gerrit using github credentials. TF-A/trusted-firmware-a · Gerrit Code Review<https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a> Gerrit Code Review review.trustedfirmware.org If not, then could you please send me the patch file (it appears copying directly from email generates corrupt patch file) Thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Andrew Scull via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 03 August 2021 22:32 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Cc: Andre Przywara <Andre.Przywara(a)arm.com>; Jimmy Brisson <Jimmy.Brisson(a)arm.com> Subject: [TF-A] TRNG SMCs intercepted by SPM-MM I've failed to figure out how to upload a CL so I'm resorting to this, it's more of a bug report anyway. There seems to be a conflict in how the standard SMCs are claimed with the TRNG SMCs claimed by SPM-MM before TRNG would get a chance to handle them properly. The patch below might fix the issue but I've not tested it or even built against ToT. ---- The TRNG SMCs use 0x84000050 to 0x84000053 which is in the range that SPM-MM claims for itself. Resolve this conflict by making SMC-MM much more selective about the SMCs it claims for itself. Signed-off-by: Andrew Scull <ascull(a)google.com> Change-Id: If86b0d6a22497d34315c61fe72645b642c6e35f3 --- include/services/spm_mm_svc.h | 12 ++---------- services/std_svc/spm_mm/spm_mm_main.c | 12 ++++++++++++ 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/include/services/spm_mm_svc.h b/include/services/spm_mm_svc.h index 3148beb80..4247c95a1 100644 --- a/include/services/spm_mm_svc.h +++ b/include/services/spm_mm_svc.h @@ -38,17 +38,8 @@ #define SPM_MM_VERSION_COMPILED SPM_MM_VERSION_FORM(SPM_MM_VERSION_MAJOR, \ SPM_MM_VERSION_MINOR) -/* These macros are used to identify SPM-MM calls using the SMC function ID */ -#define SPM_MM_FID_MASK U(0xffff) -#define SPM_MM_FID_MIN_VALUE U(0x40) -#define SPM_MM_FID_MAX_VALUE U(0x7f) -#define is_spm_mm_fid(_fid) \ - ((((_fid) & SPM_MM_FID_MASK) >= SPM_MM_FID_MIN_VALUE) && \ - (((_fid) & SPM_MM_FID_MASK) <= SPM_MM_FID_MAX_VALUE)) - /* * SMC IDs defined in [1] for accessing MM services from the Non-secure world. - * These FIDs occupy the range 0x40 - 0x5f. * [1] DEN0060A_ARM_MM_Interface_Specification.pdf */ #define MM_VERSION_AARCH32 U(0x84000040) @@ -59,7 +50,6 @@ * SMC IDs defined for accessing services implemented by the Secure Partition * Manager from the Secure Partition(s). These services enable a partition to * handle delegated events and request privileged operations from the manager. - * They occupy the range 0x60-0x7f. */ #define SPM_MM_VERSION_AARCH32 U(0x84000060) #define MM_SP_EVENT_COMPLETE_AARCH64 U(0xC4000061) @@ -94,6 +84,8 @@ int32_t spm_mm_setup(void); +bool is_spm_mm_fid(uint32_t smc_fid); + uint64_t spm_mm_smc_handler(uint32_t smc_fid, uint64_t x1, uint64_t x2, diff --git a/services/std_svc/spm_mm/spm_mm_main.c b/services/std_svc/spm_mm/spm_mm_main.c index 14c0038ba..07226b0fb 100644 --- a/services/std_svc/spm_mm/spm_mm_main.c +++ b/services/std_svc/spm_mm/spm_mm_main.c @@ -266,6 +266,18 @@ static uint64_t mm_communicate(uint32_t smc_fid, uint64_t mm_cookie, SMC_RET1(handle, rc); } +/* Predicate indicating that a function id is part of SPM-MM */ +bool is_spm_mm_fid(uint32_t smc_fid) +{ + return ((smc_fid == MM_VERSION_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH64) || + (smc_fid == SPM_MM_VERSION_AARCH32) || + (smc_fid == MM_SP_EVENT_COMPLETE_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_GET_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_SET_AARCH64)); +} + /******************************************************************************* * Secure Partition Manager SMC handler. ******************************************************************************/ -- 2.32.0.554.ge1b32706d8-goog -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 2 months

2
1
0 0

TRNG SMCs intercepted by SPM-MM

by Andrew Scull

I've failed to figure out how to upload a CL so I'm resorting to this, it's more of a bug report anyway. There seems to be a conflict in how the standard SMCs are claimed with the TRNG SMCs claimed by SPM-MM before TRNG would get a chance to handle them properly. The patch below might fix the issue but I've not tested it or even built against ToT. ---- The TRNG SMCs use 0x84000050 to 0x84000053 which is in the range that SPM-MM claims for itself. Resolve this conflict by making SMC-MM much more selective about the SMCs it claims for itself. Signed-off-by: Andrew Scull <ascull(a)google.com> Change-Id: If86b0d6a22497d34315c61fe72645b642c6e35f3 --- include/services/spm_mm_svc.h | 12 ++---------- services/std_svc/spm_mm/spm_mm_main.c | 12 ++++++++++++ 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/include/services/spm_mm_svc.h b/include/services/spm_mm_svc.h index 3148beb80..4247c95a1 100644 --- a/include/services/spm_mm_svc.h +++ b/include/services/spm_mm_svc.h @@ -38,17 +38,8 @@ #define SPM_MM_VERSION_COMPILED SPM_MM_VERSION_FORM(SPM_MM_VERSION_MAJOR, \ SPM_MM_VERSION_MINOR) -/* These macros are used to identify SPM-MM calls using the SMC function ID */ -#define SPM_MM_FID_MASK U(0xffff) -#define SPM_MM_FID_MIN_VALUE U(0x40) -#define SPM_MM_FID_MAX_VALUE U(0x7f) -#define is_spm_mm_fid(_fid) \ - ((((_fid) & SPM_MM_FID_MASK) >= SPM_MM_FID_MIN_VALUE) && \ - (((_fid) & SPM_MM_FID_MASK) <= SPM_MM_FID_MAX_VALUE)) - /* * SMC IDs defined in [1] for accessing MM services from the Non-secure world. - * These FIDs occupy the range 0x40 - 0x5f. * [1] DEN0060A_ARM_MM_Interface_Specification.pdf */ #define MM_VERSION_AARCH32 U(0x84000040) @@ -59,7 +50,6 @@ * SMC IDs defined for accessing services implemented by the Secure Partition * Manager from the Secure Partition(s). These services enable a partition to * handle delegated events and request privileged operations from the manager. - * They occupy the range 0x60-0x7f. */ #define SPM_MM_VERSION_AARCH32 U(0x84000060) #define MM_SP_EVENT_COMPLETE_AARCH64 U(0xC4000061) @@ -94,6 +84,8 @@ int32_t spm_mm_setup(void); +bool is_spm_mm_fid(uint32_t smc_fid); + uint64_t spm_mm_smc_handler(uint32_t smc_fid, uint64_t x1, uint64_t x2, diff --git a/services/std_svc/spm_mm/spm_mm_main.c b/services/std_svc/spm_mm/spm_mm_main.c index 14c0038ba..07226b0fb 100644 --- a/services/std_svc/spm_mm/spm_mm_main.c +++ b/services/std_svc/spm_mm/spm_mm_main.c @@ -266,6 +266,18 @@ static uint64_t mm_communicate(uint32_t smc_fid, uint64_t mm_cookie, SMC_RET1(handle, rc); } +/* Predicate indicating that a function id is part of SPM-MM */ +bool is_spm_mm_fid(uint32_t smc_fid) +{ + return ((smc_fid == MM_VERSION_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH32) || + (smc_fid == MM_COMMUNICATE_AARCH64) || + (smc_fid == SPM_MM_VERSION_AARCH32) || + (smc_fid == MM_SP_EVENT_COMPLETE_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_GET_AARCH64) || + (smc_fid == MM_SP_MEMORY_ATTRIBUTES_SET_AARCH64)); +} + /******************************************************************************* * Secure Partition Manager SMC handler. ******************************************************************************/ -- 2.32.0.554.ge1b32706d8-goog

4 years, 2 months

1
0
0 0

Issue with Xilinx ZynqMP FPGA loading with ATF v2.5

by Robert Hancock

After updating to ATF v2.5 on the Xilinx ZynqMP platform, I was having issues with the FPGA PL logic not loading successfully from U-Boot, it was failing with this error: PL FPGA LOAD failed with err: 0x000007d6 which is PM_RET_ERROR_TIMEOUT. The following commit introduced the timeout: commit 4d9b9b2352f9a67849faf2d4484f5fcdd2788b01 Author: Tejas Patel <tejas.patel(a)xilinx.com> Date: Thu Feb 25 02:37:09 2021 -0800 plat: xilinx: Add timeout while waiting for IPI Ack Return timeout error if, IPI is not acked in specified timeout. Signed-off-by: Tejas Patel <tejas.patel(a)xilinx.com> Change-Id: I27be3d4d4eb5bc57f6a84c839e2586278c0aec19 The timeout value (TIMEOUT_COUNT_US) is set to 0x4000 (16384) usec, which appears to be too short for the FPGA loading operation (at least on the ZCU102 board with XCZU9EG device), causing it to always timeout. Increasing the timeout to 0xF4240 usec (i.e. 1 second) fixes the issue, though some lower value may also be sufficient. -- Robert Hancock Senior Hardware Designer, Calian Advanced Technologies www.calian.com

4 years, 2 months

1
0
0 0

Re: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset"

by raghu.ncstate＠icloud.com

>> Our initial ask was to only bump the SP image entrypoint past the DTB boundary while generating SP.pkg using sptool. IIUC, the issue you brought up is for passing the manifest base address to the SP at runtime. I think these two are independent issues. Please advise. [RK] Agree here. Passing information through the manifest to the SP is orthogonal to the main problem at hand where we are assuming that the size of manifest cannot be > 4K and the entrypoint offset is always at 0x100. -Raghu -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, June 22, 2021 7:35 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Nicolas Benech <nbenech(a)nvidia.com> Subject: Re: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset" Hi Olivier, >> [OD] The two questions are which entity is loading boot data (can be a DT blob) that is to be consumed by the SP? And how is the address for boot data conveyed to the SP? The SP manifest is made for the SPMC consumption. I guess it's ok to conflate DT information required by the SP into the SP manifest. It means the bootloader loads both the SP manifest and the SP boot data in a single "SP package". In current implementation the SP has no standard way to know where the DT blob is loaded in its own memory range. We have experimental patches around the FF-A boot protocol which may help. [VW] You are right - bootloader loads SP.pkg (header+manifest+image) into memory. Can you please help me understand what "SP boot data" contains? For passing the SP manifest pointer to the SP we should ask for ideas from the community. Some ideas to get the discussion started: 1. SPMC creates a mapping for the manifest in the SP's virtual address space. SP issues a SVC call to get the virtual address from the SPMC 2. SPMC creates a mapping for the manifest in the SP's virtual address space and passes the pointer to SP via X0 3. SP manifest contains an entry to publish the virtual address for its manifest. SPMC reads this entry and maps the manifest at that virtual address during boot. >> [OD] If the assumptions (implementation defined) are that the SP boot data fits into the SP manifest, and that the SP finds this data at a fixed address (e.g. offset 0 in the SP package) then yes it can be a way to go. [VW] Our initial ask was to only bump the SP image entrypoint past the DTB boundary while generating SP.pkg using sptool. IIUC, the issue you brought up is for passing the manifest base address to the SP at runtime. I think these two are independent issues. Please advise. -Varun -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Tuesday, June 22, 2021 8:17 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Nicolas Benech <nbenech(a)nvidia.com> Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset" External email: Use caution opening links or attachments Hi Varun, (sorry last message sent too fast) See few comments inline [OD]. Regards, Olivier. ________________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: 17 June 2021 12:33 To: Olivier Deprez; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: RE: SP manifest: avoid manual updates to "entrypoint-offset" Hi, >> [OD] Ok. How is the SP informed about where to find the dtb (IPA address)? Saying this because the boot protocol between Hafnium and SPs is very much implementation specific at this moment and does not strictly follow the FF-A spec recommendations (data passing as TLVs). There is a trick that the manifest blob remains fortunately mapped from offset 0 in the SP IPA range. So it may be able to extract manifest data by mapping it the Stage-1 translation regime. But as said this does not follow a standard. [VW] We don't have a policy for all SPs, yet. At least I don't know of one. But in our experimental setup we plan to work on some assumptions e.g. assume the manifest blob to always be present at a certain address. [OD] The two questions are which entity is loading boot data (can be a DT blob) that is to be consumed by the SP? And how is the address for boot data conveyed to the SP? The SP manifest is made for the SPMC consumption. I guess it's ok to conflate DT information required by the SP into the SP manifest. It means the bootloader loads both the SP manifest and the SP boot data in a single "SP package". In current implementation the SP has no standard way to know where the DT blob is loaded in its own memory range. We have experimental patches around the FF-A boot protocol which may help. >> [OD] I think review link is mysteriously broken and the review lost. But Joao can provide the new link if necessary. I understand the intent of not making things too complex. [VW] Can we list down the next steps? Do we agree in principle that sptool needs to be upgraded to handle this use case? We can collaborate on an implementation, once we agree on the direction. [OD] If the assumptions (implementation defined) are that the SP boot data fits into the SP manifest, and that the SP finds this data at a fixed address (e.g. offset 0 in the SP package) then yes it can be a way to go. Cheers. -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Thursday, June 17, 2021 8:40 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Nicolas Benech <nbenech(a)nvidia.com> Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset" External email: Use caution opening links or attachments Hi Varun, Few comments [OD] Regards, Olivier. ________________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: 16 June 2021 14:37 To: Olivier Deprez; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: RE: SP manifest: avoid manual updates to "entrypoint-offset" Hi, >> Just a small heads up VHE SEL0 changes are tested within the Hafnium CI presently and do not relate to TF-A CI. sptool is a TF-A tool and there is no link to the Hafnium CI. [VW] Thanks for the heads up. >> what is the order in size for the manifest dtb you require in Tegra platform? Are the supplementary nodes in this manifest consumed by Hafnium or the SP itself? [VW] We can assume tens of KB. In the worst case, a few hundred KB. The manifest is targeted towards the SP and not meant for Hafnium. Just curious, do you see any pitfalls? [OD] Ok. How is the SP informed about where to find the dtb (IPA address)? Saying this because the boot protocol between Hafnium and SPs is very much implementation specific at this moment and does not strictly follow the FF-A spec recommendations (data passing as TLVs). There is a trick that the manifest blob remains fortunately mapped from offset 0 in the SP IPA range. So it may be able to extract manifest data by mapping it the Stage-1 translation regime. But as said this does not follow a standard. >> To set the complete picture, Joao had made some exploration around more dynamic SP configuration [2], maybe there are ideas to gather from there. [VW] Thanks for the links. I will review and leave comments - although we are not looking at introducing yet another script. [OD] I think review link is mysteriously broken and the review lost. But Joao can provide the new link if necessary. I understand the intent of not making things too complex. Cheers. -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Wednesday, June 16, 2021 12:59 PM To: Varun Wadekar <vwadekar(a)nvidia.com>; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Nicolas Benech <nbenech(a)nvidia.com> Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset" External email: Use caution opening links or attachments Hi Varun, See inline [OD] Regards, Olivier. ________________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: 16 June 2021 13:07 To: Olivier Deprez; tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: RE: SP manifest: avoid manual updates to "entrypoint-offset" HI Olivier, >> [OD] Just to be clear, is this about SEL0 partitions using an SEL1 >> shim No, this issue can be seen even without the shim. I don't think the usage of shim or VHE really matters here. [OD] All right. Just a small heads up VHE SEL0 changes are tested within the Hafnium CI presently and do not relate to TF-A CI. sptool is a TF-A tool and there is no link to the Hafnium CI. Not an issue as such but just making sure you have the full picture. At some point in time, when Hf VHE changes are merged we can create a specific TF-A test config to cover this case if necessary. Out of curiosity what is the order in size for the manifest dtb you require in Tegra platform? Are the supplementary nodes in this manifest consumed by Hafnium or the SP itself? >> [OD] This does not relate exactly to your problem but the effect is the "same" (aka there is more room for the manifest dtb). Agree this still requires hard-coding the entry point. At this stage I had thought of pushing the entry point even farther at a reasonably large 64KB aligned offset such that it helps with both problems. I agree, this approach is good for the short term. But I propose we craft a forward-looking solution. Are you planning on merging the sptool patch[1]? If not, I propose we come up with a way to dynamically update the SP manifest - I understand this involves adding libfdt to update the manifest. [OD] There is no pressing need to merge [1] in the short term so this can wait for a better solution. To set the complete picture, Joao had made some exploration around more dynamic SP configuration [2], maybe there are ideas to gather from there. -Varun [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Wednesday, June 16, 2021 11:42 AM To: tf-a(a)lists.trustedfirmware.org; Nicolas Benech <nbenech(a)nvidia.com> Cc: Raghupathy Krishnamurthy <raghupathyk(a)nvidia.com>; Varun Wadekar <vwadekar(a)nvidia.com> Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset" External email: Use caution opening links or attachments Hi, See few comments inline [OD] Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 16 June 2021 11:41 To: tf-a(a)lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset" Hello, We (Nico/Raghu) have been implementing SEL0 partitions for Tegra platforms [OD] Just to be clear, is this about SEL0 partitions using an SEL1 shim (as per https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… )? and recently hit an issue, where the "entrypoint-offset" field of the SP manifest [1] cannot cope with increasing manifest blobs. The way the SP manifest is created today, the "entrypoint-offset" field is set to a value *statically* by the implementer. Down the line if the manifest grows past the value written in the "entrypoint-offset", we must manually update it. This needs to be fixed. We believe there is an opportunity to upgrade the sptool to handle this situation during SP package creation, where sptool calculates the manifest size and bumps the "entrypoint-offset" past the end of the manifest. There are other ways of patching the SP manifest at runtime, but they seem sub-optimal. Please let me know if there are other ideas to solve this problem. I will post a patch to update the sptool shortly but wanted to get the ball rolling. [OD] We had an attempt (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…) to move the entry point farther in the image such that we can support 64KB granules in the Stage-1 translation regime. This does not relate exactly to your problem but the effect is the "same" (aka there is more room for the manifest dtb). Agree this still requires hard-coding the entry point. At this stage I had thought of pushing the entry point even farther at a reasonably large 64KB aligned offset such that it helps with both problems. Cheers. [1] 14. FF-A manifest binding to device tree - Trusted Firmware-A documentation<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedfi…> -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 3 months

4
11
0 0

Re: [TF-A] A Q about TZ porting guide

by Manish Pandey2

Hi Boaz, It appears that you have included plat/arm files in your platform porting which is causing Arm platform function definition to be included. Along with providing generic implementations Arm also has its own platforms(like any other partner platforms), code under plat/arm is meant only for Arm platforms. Check your make file and make sure that you don't include plat/arm/common/arm_pm.c(to avoid plat_setup_psci_ops) and plat/arm/common/aarch64/arm_helpers.S(for other functions you mentioned) this will avoid multiple definition errors. Hope this helps thanks Manish ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of IS20 Boaz Baron via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 29 July 2021 09:12 To: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; IN20 Hila Miranda-Kuzi <Hila.Miranda-Kuzi(a)nuvoton.com> Subject: Re: [TF-A] A Q about TZ porting guide Also, those functions aren’t defined as WEAK so I encountered the same problem (multiple definitions) plat_crash_console_putc plat_crash_console_flush platform_mem_init From: IS20 Boaz Baron Sent: Thursday, July 29, 2021 10:14 AM To: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org; IN20 Hila Miranda-Kuzi <Hila.Miranda-Kuzi(a)nuvoton.com> Subject: RE: [TF-A] A Q about TZ porting guide Thanks Madhukar for your answer, I think I wasn’t so clear. plat_setup_psci_ops is listed as mandatory in the porting guide. I implemented it locally but linkage fails because it is also defined in arm_pm.c. How do you suggest to avoid this multiple definition? Thanks, Boaz. From: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com<mailto:Madhukar.Pappireddy@arm.com>> Sent: Wednesday, July 28, 2021 10:44 PM To: IS20 Boaz Baron <boaz.baron(a)nuvoton.com<mailto:boaz.baron@nuvoton.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: RE: [TF-A] A Q about TZ porting guide Hi Boaz Yes, plat_setup_psci_ops() is mandatory. Every platform needs to implement it independently. You can use the implementation from [1] as a reference. I don’t think you have to delete any original function. If your platform does not support PSCI spec, you can implement a dummy function. Hope it helps. int plat_setup_psci_ops(uintptr_t sec_entrypoint, const plat_psci_ops_t **psci_ops) { return 0; } [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/c…<https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> Thanks, Madhukar From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of IS20 Boaz Baron via TF-A Sent: Wednesday, July 28, 2021 7:58 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: [TF-A] A Q about TZ porting guide Hi all, I have a Q about plat_setup_psci_ops() function implementation , In the porting guide, that function is defined as mandatory BUT the original (arm) function isn’t defined as #pargam WEAK. what should I do? to use/ delete the original function? Thanks, Boaz. ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton. ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

4 years, 3 months

1
0
0 0

Re: [TF-A] A Q about TZ porting guide

by Madhukar Pappireddy

Hi Boaz Yes, plat_setup_psci_ops() is mandatory. Every platform needs to implement it independently. You can use the implementation from [1] as a reference. I don't think you have to delete any original function. If your platform does not support PSCI spec, you can implement a dummy function. Hope it helps. int plat_setup_psci_ops(uintptr_t sec_entrypoint, const plat_psci_ops_t **psci_ops) { return 0; } [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/c… Thanks, Madhukar From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of IS20 Boaz Baron via TF-A Sent: Wednesday, July 28, 2021 7:58 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] A Q about TZ porting guide Hi all, I have a Q about plat_setup_psci_ops() function implementation , In the porting guide, that function is defined as mandatory BUT the original (arm) function isn't defined as #pargam WEAK. what should I do? to use/ delete the original function? Thanks, Boaz. ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

4 years, 3 months

2
2
0 0

TF-A Tech Forum Agenda: Thu 29th July 2021 16:00 – 17:00 (BST)

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 29th July 2021 16:00 – 17:00 (BST). Agenda: * Firmware Update Discussions - Led by Manish Badarkhe * A brief overview of firmware update mechanism as per firmware update specification release https://developer.arm.com/documentation/den0118/a/ (Version1.0 BET0). * Discuss TF-A BL2 involvement in the firmware update operation. [Patches for this work are in review: https://review.trustedfirmware.org/q/topic:%22fw-update-2%22+(status:open%2…] * Discuss existing firmware update mechanisms in the partner platforms and if any challenges to adapt to this firmware update specification. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. You have been invited to the following event. TF-A Tech Forum When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who • Bill Fletcher- creator • tf-a(a)lists.trustedfirmware.org more details »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Going (tf-a(a)lists.trustedfirmware.org)? All events in this series: Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NWlub3Ewdm1tMmk1cT…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more<https://support.google.com/calendar/answer/37135#forwarding>. Thanks Joanna

4 years, 3 months

1
0
0 0

A Q about TZ porting guide

by IS20 Boaz Baron

Hi all, I have a Q about plat_setup_psci_ops() function implementation , In the porting guide, that function is defined as mandatory BUT the original (arm) function isn't defined as #pargam WEAK. what should I do? to use/ delete the original function? Thanks, Boaz. ________________________________ The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

4 years, 3 months

1
0
0 0

Secure boot without FIP

by guillaume pivetta

Hi, I’m trying to implement a secure boot on a STM32MP1 without using the FIP file. For now , I am not able to use FIP format during the boot process so I use a depreciated boot process with TF-Av2.2 as FSBL and U-Boot as SSBL to boot my Board. My boot process do Romcode -> TF-A (BL2) -> SP_min (BL32) -> U-Boot (BL33) -> Linux kernel I succefully implemented signature authentification between U-Boot and Linux image, but between TF-A and U-Boot it’s a little bit harder. I learned on ST wiki how to sign my u-boot binary with the STM32MP_SigningTool_CLI, but when I sign my binary with a custom private key, TF-A don’t authentified it on boot, even if i tryed to pass my key to TF-A at compilation time with the BL33_KEY argument, which i think is dedicated to the FIP usage. I found, in the sources of TF-A, what I think being a developpement key, named « arm_rotpk_ecdsa.pem ». And when I sign my binary with this key, I am able to perform the signature check and continu my boot process. So I tryed to change this key with a custom one and recompile TF-A to update the key in the final binary, but it seem that it is not so simple. I found yesterday that the auth_mod_init() function wasn’t call because I had forgotten the TUSTED_BOARD_BOOT=1 compilation argument. But when I activate it, the compilation doesn’t work and i see « build/arm-trusted-firmware-v2.2/bl2/bl2_main.c:91: undefined reference to `auth_mod_init' » Whitch traditionnaly append when linker don’t find the .o where the functions are implemented. I would like to know if it is possible to implement some kind of authentification with custom keys without FIP and if yes where can i find some hints/ressources/tutorial ? I don’t find a lot of ressources about secure boot without FIP so I hope you will be able to help me.

4 years, 3 months

1
0
0 0

Re: [TF-A] Please provide option to build with GICv3 for qemu

by Jens Wiklander

Hi Alexey, On Thu, Jul 22, 2021 at 10:14 AM Alexey Kazantsev via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hello! > > Please add a build option for selecting GICv3 instead of GICv2 for QEMU > platform. > > There is the following line in plat/qemu/qemu/platform.mk : > QEMU_USE_GIC_DRIVER := QEMU_GICV2 > > It doesn't imply setting GICv3 externally by build system of other > projects, like OP-TEE. When building with OP-TEE we're overriding this assignment by passing "QEMU_USE_GIC_DRIVER=$(TFA_GIC_DRIVER)" (where TFA_GIC_DRIVER is either QEMU_GICV3 or QEMU_GICV2) on the command line. This is now tested on a regular basis since we've recently added Xen support to the OP-TEE build setup on QEMU V8 and this depends on using GICv3 instead of GICv2. Does this help in your case? Cheers, Jens

4 years, 3 months

2
1
0 0

Please provide option to build with GICv3 for qemu

by Alexey Kazantsev

Hello! Please add a build option for selecting GICv3 instead of GICv2 for QEMU platform. There is the following line in plat/qemu/qemu/platform.mk : QEMU_USE_GIC_DRIVER := QEMU_GICV2 It doesn't imply setting GICv3 externally by build system of other projects, like OP-TEE. Best regards, Aleksey.

4 years, 3 months

1
0
0 0

Re: [TF-A] [RFC] QTI platform ports violate Binary Components policy?

by Julius Werner

Hi Tom, Thanks for your interest in the SC7180 TF-A port! You're asking fair questions about a difficult situation, so let me try to add some background: The binary component policy was actually written specifically as part of the discussions about adding the SC7180 port, to lay some guidelines and ground rules about how to deal with binary components (which already existed in some other platform ports beforehand). This case was discussed in-depth with the project leaders and the trustedfirmware.org Board beforehand, and it was always understood that this would have to be a tricky compromise. As you may know, devices (e.g. Android phones) with Qualcomm chipsets generally do not run TF-A, but instead run Qualcomm's proprietary trusted OS and secure monitor (QTEE). The TF-A port was more of an experimental side project (which has by now resulted in a few SC7180-based Chromebooks being sold with TF-A, but the much larger phone market continues to use QTEE), so unfortunately the TF project's position to make demands is not yet as solid as you may think. Basically, we could have either made these compromises or continue to not support Qualcomm chipsets at all, so due to their prevalence in the ecosystem we decided it would be worth it to start like this, try to make the situation as good as it can get, and then hopefully improve on that in future chipset generations. The binary policy is meant as more of a decision guideline and individual cases are ultimately up to the Board. FWIW maybe I slightly mis-summarized the policy in the text added to the contributing.rst document -- I think saying that the *majority* of the platform port (in terms of bytes of code) should be open source, while a good ambition in general, was never realistic for SC7180. The full document in https://git.trustedfirmware.org/tf-binaries.git/tree/readme.rst instead says "Binary components that contain all meaningful functionality of a platform port" are not accepted -- the intention is that there are pieces large enough to be worth modifying in the open source part, while allowing vendors to keep functionality proprietary that they absolutely do not want (or are not allowed) to disclose. For SC7180, things like UART, SPMI, PMIC and RNG drivers as well as SMC validation are implemented in open source (and as you noticed some of those were ported piecemeal at later points of the development process). I'll be the first to admit that this isn't a lot and we absolutely want to do more, but it is a tricky and very time-consuming process both in identifying the exact parts that can be open-sourced without IP concerns and then actually doing the work (since the qtiseclib code is still proprietary even if there is a Linux driver for the same subsystem, we can't just copy things over, it has to be carefully rewritten and revalidated). The state you see the SC7180 port in right now is basically just as far as we got over the course of this project (and believe me it took a lot of effort already, even if it may not look like much). Hopefully we can make further progress with the next chipset. Also, just as a note, we didn't actually end up hosting qtiseclib in the TF binary repository in the end, due to concerns about details in the license text that couldn't be resolved. It is instead hosted by the coreboot.org project at the moment. I'm not sure if this technically means that the TF binary component policy applies to this blob or not (from a strict reading of the text I would say it doesn't), but that's not really that relevant... like I said, in the end the Board makes final decisions about whether a platform port is accepted into the repository or not on a case by case basis, and the policy is just a general guideline. The general goal is to make sure the TF-A ports are actually useful to open source developers while allowing for pragmatic compromises in tricky situations like this, and in this case we decided that allowing this port would be more useful than not (although it's certainly on the edge). On Tue, Jul 20, 2021 at 2:05 AM Tom Johnsen <tomjohnsen(a)protonmail.com> wrote: > > Hello! > > I recently discovered the TF-A port for QTI SC7180 and was very happy > to see this. I always thought it would have been great if Qualcomm made > (open-source) TF-A ports for their platforms. For example, I would be > interested in TF-A for the DragonBoard 820c (APQ8096E). > Unfortunately, after talking to some other people I have been told > it is unlikely that Qualcomm will ever have this. :-/ > > I am not much of a firmware developer but I was curious so I wanted to > check how much SoC-specific code is actually needed for a TF-A port. At > first I was surprised - the QTI platform ports seem fairly simple, there > is not much SoC-specific code at all. However, it looks like the reason for > that is that almost all of the SoC-specific code is actually contained in a > proprietary "qtiseclib" blob that is statically linked into the bl31.bin. > > I did not really expect to see something like that in a public > open-source project, especially not one as security-critical as TF-A. > It looks like some binary components are indeed allowed as per the > Contribution Guidelines (1). Yet, after reading them and looking at the > code again I wonder how the amount of functionality implemented > in the "qtiseclib" could really conform to these guidelines? > > I quote them here (from (1)) for convenience: > > > Binary components must be restricted to only the specific > > functionality that cannot be open-sourced and must be linked into a > > larger open-source platform port. The majority of the platform port > > must still be implemented in open source. Platform ports that are > > merely a thin wrapper around a binary component that contains all the > > actual code will not be accepted. > > There are two main reasons why I do not think that the "qtiseclib" > conforms to these guidelines. > > --- 1. "Majority of the platform port must be open-source" --- > > I have built TF-A for QTI SC7180 according to the documentation (2). > The resulting bl31.bin has a size of 182088 bytes. The linker conveniently > produces a "bl31.map" file that shows exactly which part of the binary > comes from which component of the TF-A port. It can be analyzed easily, > for example with fpv-gcc (3). > > The following table shows the distribution of the bl31.bin: > > +-------------+----------+-----+ > | Component | Size (B) | % | > +-------------+----------+-----+ > | libqtisec.a | 147344 | 81% | > | Other BL31 | 23838 | 13% | > | plat/qti | 5222 | 3% | > | Padding | 3863 | 2% | > | libc.a | 1821 | 1% | > +-------------+----------+-----+ > > Clearly, the libqtisec.a dominates with 81%. The open-source part of the > QTI TF-A platform port (plat/qti) is merely 3% of the final binary. > > Perhaps it is just large static data tables? The following table shows > only the distribution of .text symbols (excluding libc and "Other BL31"): > > +-------------+----------+-----+ > | Component | Size (B) | % | > +-------------+----------+-----+ > | libqtisec.a | 75792 | 95% | > | plat/qti | 3920 | 5% | > +-------------+----------+-----+ > > I do not see any way to interpret this as "the majority of the platform > port is open-source". It is hard to find any substantial functionality > that does not end up calling into the proprietary qtiseclib. In my > opinion, the port is hardly more than "a thin wrapper around a binary > component" which is explicitly forbidden in the guidelines. > > --- 2. "Binary components should be as minimal as possible" --- > > It is hard to judge this given that the license for "qtiseclib" (obviously) > does not allow reverse-engineering. However, just judging from some of the > symbol names that I see visibly in the "bl31.map" Qualcomm seems to have > spent little effort to keep the binary component actually minimal. > > "qtiseclib" also contains code for IP blocks that have public > open-source drivers in Linux, including for: > > - TLMM (GPIO) > - GCC (Clocks) > - rpmh > > Perhaps some "secret" registers are programmed there but it is hard to > believe that there is no overlap that could have been made open-source. > > This is also quite visible based on changes that were made later. > The PRNG and SPMI driver were moved out of "qtiseclib" later (4, 5) > and both can be found similarly in Linux. > > --- Conclusion --- > > How does this conform to the Binary Components policy that is part of > the contribution guidelines? Was this not checked during review? > > All in all I cannot help but get the feeling that Qualcomm has fairly > little interest to have open-source firmware. Not even simple hardware > initialization that probably exists similarly in open-source drivers > has been implemented in open-source code. The resulting bl31.bin can > be hardly called "open-source" when 81% of it is actually proprietary. > > If this is intended and considered acceptable I suggest rewriting the > "Binary Components" policy to explicitly allow vendors to require > any amount of proprietary code for their TF-A ports. Personally, I think > this is a very bad idea though and just encourages all other vendors to > do the same in the future. TF-A (as a trusted reference implementation) > is in a good position to make certain demands that must be met for > inclusion in the upstream tree. > > I am mainly sad about this because this certainly means that only > Qualcomm can make such ports by providing the "qtiseclib" that contains > most of the functionality. Perhaps open-source code could have been > adjusted by the community to other platforms with some effort. > > Thanks for reading. > ~ Tom > > (1) https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm… > (2) https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti.html > (3) https://github.com/ebs-universe/fpv-gcc > (4) https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4885 > (5) https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4409

4 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A