- TF-A - lists.trustedfirmware.org

by Ruth Glushkin

Commit No: 71b6e2217052057744a1dedaef1c540f3c98e703 feat(plat): added support to Nuvoton npcm845x chip Please review. Margarita Glushkin

2 years, 1 month

2
1
0 0

RFE: GIC workaround for NVIDIA erratum T241-FABRIC-4

by Varun Wadekar

Hi, I would like to get some feedback on the gicv3 workaround [1] for NVIDIA erratum T241-FABRIC-4. The commit description describes the erratum and the fix in detail. The patch is only to start a dialogue and gather feedback on the way forward. Please advise. Thanks. [1] fix(gicv3): workaround for NVIDIA erratum T241-FABRIC-4 (I04e33ba6) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/19969>

2 years, 2 months

1
1
0 0

Re: Post-boot loading of OP-TEE

by 梅建强(禹夜)

Hi, experts, I have another two other questions about this issue. (1) What should I do if the current optee to load already exists or I want to update optee? The most straightforward way I could think of is to reclaim the memory currently used by optee, then reload the optee image and initialize it. (2) optee may use multiple cores. When and how to process the initialization of multiple cores? Do you have any solutions or ideas? Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年3月11日(星期六) 21:44 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; tf-a <tf-a(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org> 抄　送：Dan Handley <Dan.Handley(a)arm.com>; Jeffrey Kardatzke <jkardatzke(a)google.com>; jwerner <jwerner(a)chromium.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org> 主　题：Re: Post-boot loading of OP-TEE Hi, experts, If I want to apply the code to the S-EL2 framework (Hafnium as SPMC), What special processing should be added to spmd_handle_smc_load function or other function, such as context restore and save? I'm not clear about the details of the process, can you give me some help? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年1月9日(星期一) 15:39 收件人：tf-a <tf-a(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org> 抄　送：Dan Handley <Dan.Handley(a)arm.com>; Jeffrey Kardatzke <jkardatzke(a)google.com>; jwerner <jwerner(a)chromium.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org> 主　题：Post-boot loading of OP-TEE Hi, The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way of post-boot loading OP-TEE by the Linux kernel with signature verification in the normal world only. This has previously been discussed in this mail thread [2] about half a year ago. Ultimately, it was concluded that this should in principle be accepted upstream as a platform choice to allow this or not. There are concerns that what we have in upstream TF-A should serve as good examples, and trusting the normal world to verify secure world software might not meet that criterion. There are also concerns about adding signature verification to BL31 Leaving the secure world wide open until the Linux kernel has been able to successfully load and verify an OP-TEE binary seems very risky. Even if it's claimed that the normal world can be trusted at this point, we're still giving up a critical level of defense without a good reason. I've started to review [1], but it should not be accepted for merging without support and approval from other maintainers. I would like to explore other options in this mail thread. In [2] it was suggested that a remnant of bl2 could be kept to verify OP-TEE before starting to execute it. This could be taken one step further and load a limited OP-TEE at boot which later is updated live, almost like what's discussed in [3]. This should minimize the impact on TF-A and also leave OP-TEE in charge of accepting an update instead of a divided responsibility between the normal world and TF-A. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 > [2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… <https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… > [3] https://github.com/OP-TEE/optee_os/issues/5699 <https://github.com/OP-TEE/optee_os/issues/5699 > Thanks, Jens

2 years, 2 months

2
1
0 0

Re: Post-boot loading of OP-TEE

by 梅建强(禹夜)

Hi, experts, If I want to apply the code to the S-EL2 framework (Hafnium as SPMC), What special processing should be added to spmd_handle_smc_load function or other function, such as context restore and save? I'm not clear about the details of the process, can you give me some help? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年1月9日(星期一) 15:39 收件人：tf-a <tf-a(a)lists.trustedfirmware.org>; OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org> 抄　送：Dan Handley <Dan.Handley(a)arm.com>; Jeffrey Kardatzke <jkardatzke(a)google.com>; jwerner <jwerner(a)chromium.org>; raghu.ncstate <raghu.ncstate(a)icloud.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org> 主　题：Post-boot loading of OP-TEE Hi, The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way of post-boot loading OP-TEE by the Linux kernel with signature verification in the normal world only. This has previously been discussed in this mail thread [2] about half a year ago. Ultimately, it was concluded that this should in principle be accepted upstream as a platform choice to allow this or not. There are concerns that what we have in upstream TF-A should serve as good examples, and trusting the normal world to verify secure world software might not meet that criterion. There are also concerns about adding signature verification to BL31 Leaving the secure world wide open until the Linux kernel has been able to successfully load and verify an OP-TEE binary seems very risky. Even if it's claimed that the normal world can be trusted at this point, we're still giving up a critical level of defense without a good reason. I've started to review [1], but it should not be accepted for merging without support and approval from other maintainers. I would like to explore other options in this mail thread. In [2] it was suggested that a remnant of bl2 could be kept to verify OP-TEE before starting to execute it. This could be taken one step further and load a limited OP-TEE at boot which later is updated live, almost like what's discussed in [3]. This should minimize the impact on TF-A and also leave OP-TEE in charge of accepting an update instead of a divided responsibility between the normal world and TF-A. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 > [2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… <https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… > [3] https://github.com/OP-TEE/optee_os/issues/5699 <https://github.com/OP-TEE/optee_os/issues/5699 > Thanks, Jens

2 years, 2 months

1
0
0 0

Errata ABI Design and Implementation

by Sona Rebecca Mathew

Hi all, I presented the Errata ABI design and Implementation in this week's tech forum; the patches are available for review, and any feedback, discussions are welcome. Link to the patch : feat(errata_abi): errata management firmware interface (I70f0e256) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/19835> The team would like to merge this feature by the end of March, kindly help review and provide feedback. Thanks -Sona

2 years, 2 months

1
0
0 0

Errata framework proposal

by Boyan Karatotev

Hi all, As presented on this week's tech forum, I have recently been working on a framework to improve errata implementations, consolidate the disparate requirements around them, and make errata information available at runtime. This is related, but separate to the errata ABI which is being worked on by Sona. Patches are available for review [1] and feedback is welcome. This email is to host discussion around the proposal, especially things that came up during the tech forum. The team would like to merge this sometime in April, but the sooner it is accepted, the sooner we can start (and complete!) the migration. [1]: https://review.trustedfirmware.org/q/topic:%22bk%252Ferrata_refactor%22+

2 years, 2 months

1
0
0 0

About kdump hang issue in SDEI dispatch

by Ming Huang

Hi James & TF-A guys, When hest acpi table configure Hardware Error Notification type as Software Delegated Exception(0x0B) for RAS event, kernel RAS interacts with TF-A by SDEI mechanism. On the firmware first system, kernel was notified by TF-A sdei call. The calling flow like as below when fatal RAS error happens: TF-A notify kernel flow: sdei_dispatch_event() ehf_activate_priority() call sdei callback // callback registered by kerenl ehf_deactivate_priority() Kernel sdei callback: sdei_asm_handler() __sdei_handler() _sdei_handler() sdei_event_handler() ghes_sdei_critical_callback() ghes_in_nmi_queue_one_entry() /* if RAS error is fatal */ __ghes_panic() panic() If fatal RAS error occured, panic was called in sdei_asm_handle() without ehf_deactivate_priority executed, which lead interrupt masked. If interrupt masked, system would be halted in kdump flow like this: arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for cmdq arm-smmu-v3 arm-smmu-v3.3.auto: allocated 32768 entries for evtq arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for priq arm-smmu-v3 arm-smmu-v3.3.auto: SMMU currently enabled! Resetting... So interrupt should be restored before panic otherwise kdump will hang. In the process of sdei, a SDEI_EVENT_COMPLETE(or SDEI_EVENT_COMPLETE_AND_RESUME) call should be called before panic for a completed run of ehf_deactivate_priority(). The ehf_deactivate_priority() function restore pmr_el1 to original value(>0x80). The SDEI dispatch flow was broken if SDEI_EVENT_COMPLETE was not be called. This will bring about two issue: 1 Kdump will hang for firmware reporting fatal RAS event by SDEI; (as explain above) 2 For NMI scene，TF-A enable a secure timer, the PPI 29 will trigger periodically. Kernel register a callback for hard lockup. The below code will not be called when panic in kernel callback: TF-A, services/std_svc/sdei/sdei_intr_mgmt.c sdei_intr_handler(): /* * We reach here when client completes the event. * * If the cause of dispatch originally interrupted the Secure world, * resume Secure. * * No need to save the Non-secure context ahead of a world switch: the * Non-secure context was fully saved before dispatch, and has been * returned to its pre-dispatch state. */ if (sec_state == SECURE) restore_and_resume_secure_context(); /* * The event was dispatched after receiving SDEI interrupt. With * the event handling completed, EOI the corresponding * interrupt. */ if ((map->ev_num != SDEI_EVENT_0) && !is_map_bound(map)) { ERROR("Invalid SDEI mapping: ev=%u\n", map->ev_num); panic(); } plat_ic_end_of_interrupt(intr_raw); How to fix above issues? I think the root cause is that kernel broken the SDEI dispatch flow, so kernel should modify to fix these issues. Thanks, Ming

2 years, 2 months

4
10
0 0

Need to activate MEASURE_BOOT on nxp ls1043 platform

by Benoit Sansoni

Hello, I am working on a board based on NXP LS1043 processor (arm64) with TPM2 on SPI interface. I have the following boot sequence : TF-A + UBOOT + YOCTO. I have a look on the code where the TF-A MEASURE_BOOT was implemented for the fvp arm platform using OPTEE fTPM. As far as I understood, the event log is implemented based on the TCG2 EFI PROTOCOL from commit : commit 3ee148d6439b69d326f8e6d2a4ce822604e0e64c Merge: 43f7d8879 4a135bc33 Author: joanna.farley <joanna.farley(a)arm.com> Date: Wed Jul 22 16:35:11 2020 +0000 Nevertheless, I am surprised because I did not find any TPM2 driver in the current TF-A code. I would like to know : 1. How to port what was done for the fvp platform to my platform ? 2. What is code hashed in the TFA to create the event log ? 3. Why are there no TPM2 routine in the TF-A to expend PCR ? Thanks in advance for your help Benoit

2 years, 2 months

2
1
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, 2 months

8
18
0 0

u-boot image for MACCHIATObin Single Shot builds but won't boot

by Maciej Sieczka

Hello, I'm a noob here, and I need help. I've just built flash-image.bin for my MACCHIATObin Single Shot as follows, but it fails to boot - as follows further below: - git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git - Clone the binaries-marvell and mv-ddr-marvell Git repos alongside the trusted-firmware-a, and check out revisions as recommeded in TF-A build instructions for Armada80x0 (https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/buil…). - export CROSS_COMPILE=/my/path/to/arm-gnu-toolchain/11.3.rel1-x86_64-aarch64-none-elf/bin/aarch64-none-elf- - Build u-boot.bin: - git clone https://source.denx.de/u-boot/u-boot.git alongside the binaries-marvell and mv-ddr-marvell repos. - cd u-boot - git checkout v2023.01 - the latest release. - make mvebu_mcbin-88f8040_defconfig - Change CONFIG_DEFAULT_DEVICE_TREE to "armada-8040-mcbin-singleshot" (inspired by this SolidRun doc: https://github.com/SolidRun/documentation/blob/bsp/8040/u-boot.md). - Add arch/arm/dts/armada-8040-mcbin-singleshot.dts. Can be obtained e.g. from the latest Marvell kernel sources (https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/marvell/). - make - Built fine. - Build TF-A: - cd ../trusted-firmware-a/ - git checkout v2.8.0 - the latest release, as per changelog (https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html). - make PLAT=a80x0_mcbin MV_DDR_PATH=../mv-ddr-marvell SCP_BL2=../binaries-marvell/mrvl_scp_bl2.img BL33=../u-boot/u-boot.bin mrvl_flash - Built fine. Then I flashed the flash-image.bin onto my SD card: dd if=trusted-firmware-a/build/a80x0_mcbin/release/flash-image.bin of=/dev/mmcblk0 seek=4096 conv=fdatasync,notrunc (as per https://archlinuxarm.org/platforms/armv8/marvell/macchiatobin). It boots, but complains about a missing serial driver and resets in a loop: --- BootROM - 2.03 Starting CP-0 IOROM 1.07 Booting from SD 0 (0x29) Found valid image at boot postion 0x002 lNOTICE: Starting binary extension NOTICE: SVC: DEV ID: 8040, FREQ Mode: 0xd NOTICE: SVC: AVS work point changed from 0x29 to 0x29 mv_ddr: devel-g541616b (Mar 05 2023 - 14:15:32) mv_ddr: completed successfully NOTICE: Cold boot NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.8(release):v2.8 NOTICE: BL1: Built : 14:15:45, Mar 5 2023 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.8(release):v2.8 NOTICE: BL2: Built : 14:15:48, Mar 5 2023 NOTICE: SCP_BL2 contains 7 concatenated images NOTICE: Load image to CP1 MG NOTICE: Loading MG image from address 0x402305c Size 0xe0f0 to MG at 0xf4100000 NOTICE: Load image to CP0 MG NOTICE: Loading MG image from address 0x403114c Size 0xe0f0 to MG at 0xf2100000 NOTICE: Skipping MSS CP3 related image NOTICE: Skipping MSS CP2 related image NOTICE: Load image to CP1 MSS AP0 NOTICE: SECURELY Loading MSS FW from addr. 0x4042c34 Size 0x1cfc to MSS at 0xf4280000 NOTICE: CP MSS startup is postponed NOTICE: Done NOTICE: Load image to CP0 MSS AP0 NOTICE: SECURELY Loading MSS FW from addr. 0x4044930 Size 0x1cfc to MSS at 0xf2280000 NOTICE: CP MSS startup is postponed NOTICE: Done NOTICE: Load image to AP0 MSS NOTICE: Loading MSS FW from addr. 0x404662c Size 0x5400 to MSS at 0xf0580000 NOTICE: Done NOTICE: SCP Image doesn't contain PM firmware NOTICE: BL1: Booting BL31 lNOTICE: Starting CP0 MSS CPU NOTICE: Starting CP1 MSS CPU NOTICE: MSS PM is not supported in this build NOTICE: BL31: v2.8(release):v2.8 NOTICE: BL31: Built : 14:15:55, Mar 5 2023 <debug_uart> No serial driver found resetting ... --- Can anyone advise how to fix this? Is this list even the right place to ask such questions? Maciej -- Maciej Sieczka http://www.sieczka.org

2 years, 2 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. 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 383288: (CHECKED_RETURN) /mbedtls/library/bignum.c: 1670 in mbedtls_mpi_exp_mod() /mbedtls/library/bignum.c: 1867 in mbedtls_mpi_exp_mod() ________________________________________________________________________________________________________ *** CID 383288: (CHECKED_RETURN) /mbedtls/library/bignum.c: 1670 in mbedtls_mpi_exp_mod() 1664 * 1665 * To achieve this, we make a copy of X and we use the table entry in each 1666 * calculation from this point on. 1667 */ 1668 const size_t x_index = 0; 1669 mbedtls_mpi_init( &W[x_index] ); >>> CID 383288: (CHECKED_RETURN) >>> Calling "mbedtls_mpi_copy" without checking return value (as is done elsewhere 43 out of 46 times). 1670 mbedtls_mpi_copy( &W[x_index], X ); 1671 1672 j = N->n + 1; 1673 /* All W[i] and X must have at least N->n limbs for the mpi_montmul() 1674 * and mpi_montred() calls later. Here we ensure that W[1] and X are 1675 * large enough, and later we'll grow other W[i] to the same length. /mbedtls/library/bignum.c: 1867 in mbedtls_mpi_exp_mod() 1861 MBEDTLS_MPI_CHK( mbedtls_mpi_add_mpi( &W[x_index], N, &W[x_index] ) ); 1862 } 1863 1864 /* 1865 * Load the result in the output variable. 1866 */ >>> CID 383288: (CHECKED_RETURN) >>> Calling "mbedtls_mpi_copy" without checking return value (as is done elsewhere 43 out of 46 times). 1867 mbedtls_mpi_copy( X, &W[x_index] ); 1868 1869 cleanup: 1870 1871 /* The first bit of the sliding window is always 1 and therefore the first 1872 * half of the table was unused. */ ** CID 383287: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 383287: Null pointer dereferences (FORWARD_NULL) /mbedtls/library/rsa_alt_helpers.c: 134 in mbedtls_rsa_deduce_primes() 128 129 for( ; attempt < num_primes; ++attempt ) 130 { 131 mbedtls_mpi_lset( &K, primes[attempt] ); 132 133 /* Check if gcd(K,N) = 1 */ >>> CID 383287: Null pointer dereferences (FORWARD_NULL) >>> Passing "P" to "mbedtls_mpi_gcd", which dereferences null "P->p". 134 MBEDTLS_MPI_CHK( mbedtls_mpi_gcd( P, &K, N ) ); 135 if( mbedtls_mpi_cmp_int( P, 1 ) != 0 ) 136 continue; 137 138 /* Go through K^T + 1, K^(2T) + 1, K^(4T) + 1, ... 139 * and check whether they have nontrivial GCD with N. */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

2 years, 2 months

1
0
0 0

[PATCH] fix(mmc): remove redundant reset_to_idle call

by Baruch Siach

mmc_enumerate() is the only caller of mmc_send_op_cond(). mmc_enumerate() calls mmc_reset_to_idle() just before calling mmc_send_op_cond(). No need to do that again in mmc_send_op_cond(). Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> Change-Id: Ib8c8ed1a559e3fecb315245f91bb3dc1f547d820 --- Sending the patch to the list once again. review.trustedfirmware.org does not work for me. https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… --- drivers/mmc/mmc.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 2b727d4e7696..57f47482013a 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -452,11 +452,6 @@ static int mmc_send_op_cond(void) int ret, n; unsigned int resp_data[4]; - ret = mmc_reset_to_idle(); - if (ret != 0) { - return ret; - } - for (n = 0; n < SEND_OP_COND_MAX_RETRIES; n++) { ret = mmc_send_cmd(MMC_CMD(1), OCR_SECTOR_MODE | OCR_VDD_MIN_2V7 | OCR_VDD_MIN_1V7, -- 2.39.2

2 years, 2 months

2
1
0 0

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

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Mar 23, 2023 ⋅ 4pm – 5pm United Kingdom Time Rescheduling the 2&4 world RAS architectural changes discussion.More details nearer the event.----------------We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 2 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Mar 9, 2023 ⋅ 4pm – 5pm United Kingdom Time Changing this session for Errata ABI and Errata Framework discussions.A more detailed agenda will be issued closer to the event.---------------------We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org Michal Simek don.harbin(a)linaro.org ulf.hansson(a)linaro.org moritzf(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

2 years, 2 months

1
0
0 0

Is NS_BL1U necessary to do FWU ?

by Jun.Chen(陳奕昕)

Hi, In ARM TBBR, there is a requirement “R0100_TBBR_AFM_FLASHING” (The AP firmware must switch to the Non-Trusted world for executing the SoC firmware loader), But there is no requirement for secure boot as long as I finish chain if ROT verification. So, can I implement FWU in BL2 which is verified and load from BL1 (ROM)? For example, BL1(ROM) -> Load and verify BL2U with new image from SD to secure RAM -> execute BL2U in Secure RAM then write new image to NAND flash Best regards, Jun

2 years, 2 months

2
3
0 0

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

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Mar 9, 2023 ⋅ 4pm – 5pm United Kingdom Time Reserving this session for a TF-A RAS support update in an evolving Arm architecture.A more detailed agenda will be issued closer to the event.---------------------We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 2 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Feb 23, 2023 8am - 9am (PST) (tf-a@lists.trustedfirmware.org)

by wingers＠google.com

This event has been updated Changed: location TF-A Tech Forum Thursday Feb 23, 2023 ⋅ 8am – 9am Pacific Time - Los Angeles Location US-MTV-1015-1-S-Silicon (2) [GVC, Phone] https://www.google.com/maps/search/US-MTV-1015-1-S-Silicon+(2)+%5BGVC,+Phon… Agenda UpdateTitle:PSCI OS-initiated mode in TF-APresented by:Maulik Shah, Ulf Hansson, Wing LiAgenda:1. Overview of OS-initiated mode2. Why OS-initiated mode?3. Implementation details and testing in TF-AThanks AllJoanna===============================We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org don.harbin(a)linaro.org sudeep.holla(a)arm.com Souvik Chakravarty wingers(a)google.com ajaysp(a)google.com peckham(a)google.com Mahesh Sivasubramanian cozette(a)google.com mkshah(a)qti.qualcomm.com ulf.hansson(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

2 years, 2 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Feb 23, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Feb 23, 2023 ⋅ 4pm – 5pm United Kingdom Time Agenda UpdateTitle:PSCI OS-initiated mode in TF-APresented by:Maulik Shah, Ulf Hansson, Wing LiAgenda:1. Overview of OS-initiated mode2. Why OS-initiated mode?3. Implementation details and testing in TF-AThanks AllJoanna===============================We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org don.harbin(a)linaro.org sudeep.holla(a)arm.com Souvik Chakravarty wingers(a)google.com ajaysp(a)google.com peckham(a)google.com Mahesh Sivasubramanian cozette(a)google.com mkshah(a)qti.qualcomm.com ulf.hansson(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

2 years, 2 months

1
0
0 0

Checking SIP Service Calls range

by Michal Simek

Hi, I have one question about SIP Service Calls range and it's range checking. Based on DEN0028E SIP Service Calls ranges are 0x82000000-0x8200FFFF SMC32: SiP Service Calls 0xC2000000-0xC200FFFF SMC64: SiP Service Calls That's the ranges which we are using for implementing SOC specific SMC handlers and I found that in past it was also added code which is out of this range. Specifically in Xilinx ZynqMP you can see code like this if (is_em_fid(smc_fid)) { return em_smc_handler(smc_fid, x1, x2, x3, x4, cookie, handle, flags); } where EM range is 0x820e0001- 0x820e0003 is out of our range which is assigned to us. But there is no failure at all that we are out of ranged in spec. Shouldn't this be enforced by core itself? That's why I just wanted to know your opinion about it. We will definitely implement better masking to find out that 0x00fe0000 are all zeros. But that bit 16 is based on DEN0028E related to smcccv1.3 which I think we are not supporting now that's why should be 0 too. But definitely some information about this bit should be useful. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs

2 years, 3 months

2
2
0 0

[LTS v2.8.0] Trusted Firmware-A LTS v2.8.0 Release Announcement

by Varun Wadekar

External email: Use caution opening links or attachments We are pleased to announce the release of the Trusted Firmware-A LTS version 2.8.0 [1]. To help with the verification and stability of the release, we also created side branches for Trusted Firmware-A Tests [2] and TF-A OpenCI Scripts/Jobs [3]. These went live on 13th February 2023. The trusted-firmware-a repository is now open again. On behalf of the TF-A LTS project maintainers, I would like to thank the Trustedfirmware.org TF-A Project community for the support and guidance. Notable features of the TF-A LTS Version 2.8.0 Release are as follows: TF-A Project Repository * Resolved issues * Workarounds for the following CPU errata * Cortex-A510 erratum 2684597 * Cortex-A710 erratum 2282622 * Cortex-A710 erratum 2768515 * Cortex-A78 erratum 2772019 * Cortex-A78 erratum 2779479 * Cortex-A78C erratum 2772121 * Cortex-X2 erratum 2282622 * Cortex-X2 erratum 2768515 * Cortex-X3 erratum 2615812 * Neoverse N2 erratum 2743089 * Neoverse V1 erratum 2743093 * Neoverse V1 errata 2779461 * Mitigations for the security advisory #10 * Critical bug fixes for the following platforms * Arm/CSS * Intel * Layerscape * LS1046a * LX2 * NXP * ST Patch Statistics * 35 Patches merged since v2.8 Nov 2022 release Please refer to the TF-A LTS [1] changelog for the complete summary of changes. [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/chang… [2] tf-a-tests.git - Trusted Firmware-A Tests<https://git.trustedfirmware.org/TF-A%2Ftf-a-tests.git/log/?h=refs%2Fheads%2…> [3] tf-a-ci-scripts.git - Trusted Firmware A (TF-A) CI scripts<https://git.trustedfirmware.org/ci%2Ftf-a-ci-scripts.git/log/?h=refs%2Fhead…> [4] tf-a-job-configs.git - Trusted Firmware A (TF-A) Jenkins job configs<https://git.trustedfirmware.org/ci%2Ftf-a-job-configs.git/log/?h=refs%2Fhea…>

2 years, 3 months

1
0
0 0

Coding guidelines update: Discouraging usage of weak functions

by Sandrine Bailleux

Hi all, As you may know, the TF-A project historically used to make heavy use of weak functions. The code base has numerous examples of them. However, based on previous discussions, I think we have general consensus in the TF-A community that the disadvantages of weak functions outweigh their benefits and for this reason we should discourage introducing new ones. In practice, I think this policy is already enforced most of the time in code reviews but I've now posted a patch that makes it explicit in the project's coding guidelines and provide the rationale behind it. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/19398 Note that TF-A maintainers would still be responsible for enforcing this policy, as the CI system won't flag that for them, mainly because I think there might be legitimate cases for weak functions in rare instances so we'd get some false positives from such checks. We (at Arm) have got plans to gradually convert existing weak functions to strongly-defined implementations across the code base but this will take time. Like I said, I don't expect this change to be too controversial but please raise any concerns you may have in this email thread or on Gerrit. Best regards, Sandrine

2 years, 3 months

3
6
0 0

[PATCH 1/2] fix(cert-create): move WARN to higher priority than NOTICE

by Baruch Siach

NOTICE messages should require higher LOG_LEVEL than WARN, not the other way around. Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> Change-Id: Iba9c67cafed19be47e7d03198faa98fbf99a10ee --- I still can't upload to review.trustedfirmware.org so I'm once again sending to the list instead. https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… --- tools/cert_create/include/debug.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/cert_create/include/debug.h b/tools/cert_create/include/debug.h index ee8f1f51786f..8f7c62eefe2d 100644 --- a/tools/cert_create/include/debug.h +++ b/tools/cert_create/include/debug.h @@ -20,8 +20,8 @@ #define LOG_LEVEL_NONE 0 #define LOG_LEVEL_ERROR 10 -#define LOG_LEVEL_NOTICE 20 -#define LOG_LEVEL_WARNING 30 +#define LOG_LEVEL_WARNING 20 +#define LOG_LEVEL_NOTICE 30 #define LOG_LEVEL_INFO 40 #define LOG_LEVEL_VERBOSE 50 -- 2.39.0

2 years, 3 months

2
2
0 0

[LTS v2.8.0] RC0 tag has been created

by Varun Wadekar

Hello, As announced in the last Tech forum, the code freeze date for the LTS branch was Feb 3, 2023. We have now merged all the patches published on the wiki [1]. The branch is still locked, and all the CI test runs have now been completed. We are trying to root cause one test failure, though. The RC0 tag was created today, and we request platform owners test the branch [2] on their downstream platforms if they wish. We are still on track to release on Feb 10 and will publish more updates shortly. Thanks. [1] ⚡ LTS Tracking for v2.8.x (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…>. [2] trusted-firmware-a.git - Trusted Firmware for A profile Arm CPUs<https://git.trustedfirmware.org/TF-A%2Ftrusted-firmware-a.git/log/?h=refs%2…>

2 years, 3 months

1
0
0 0

[LTS v2.8.0] The branch is now locked

by Varun Wadekar

External email: Use caution opening links or attachments Hello, As announced in the last Tech forum, the code freeze date for the LTS branch is Feb 3, 2023. We have now locked the branch and won’t be accepting any more commits. The list of the commits that will be merged into the LTS branch can be found at ⚡ LTS Tracking for v2.8.x (trustedfirmware.org)<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…>. If there are commits that we missed or that need to be in the LTS branch, please reach out to us. We will post more updates shortly. Thanks.

2 years, 3 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been updated with a note: "Updating the agenda for the TF-A Tech Forum session on Feb 9th 2023." Changed: description TF-A Tech Forum Thursday Feb 9, 2023 ⋅ 4pm – 5pm United Kingdom Time Title: Firmware update support in the Trusted Services projectPresented by: Julian HallA reference implementation of the Update Agent has recently been added to Trusted Services. The implementation provides a toolbox of reusable components for adding banked FWU support into firmware for A-Profile devices. The implementation conforms to the Arm FWU-A specification for compatibility with TF-A and other boot loaders that recognise FWU-A metadata.===================================We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org julian.hall(a)arm.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

2 years, 3 months

1
0
0 0

[LTS v2.8.0] TF-A patches are now ready for merge

by Varun Wadekar

Hello, As announced in the last Tech forum, the code freeze date for the LTS branch is Feb 3, 2023. We have started shortlisting the patches for the lts-v2.8 branch. These are the commits that will be merged into the LTS branch. More details can be found at ⚡ LTS Tracking for v2.8.x (trustedfirmware.org)<https://developer.trustedfirmware.org/w/tf_a/tf-a_lts_meeting_minutes/track…> 1. c7e698cfd fix(cpus): workaround for Cortex-X3 erratum 2615812 2. c45791b2f fix(layerscape): fix errata a008850 3. fa0105693 fix(nxp-ddr): use CDDWW for write to read delay 4. 00bb8c37e fix(nxp-ddr): apply Max CDD values for warm boot 5. 07d8e34fd fix(nxp-drivers): fix tzc380 memory regions config 6. c0c157a68 fix(ls1046a): 4 keys secureboot failure resolved 7. 50aa0ea7a fix(lx2): init global data before using it 8. 4daeaf341 fix(sptool): add dependency to SP image 9. 5fb6946ad fix(console): fix crash on spin_unlock with cache disabled 10. ff1d2ef38 fix(el3_runtime): restore SPSR/ELR/SCR after esb 11. c42402cdf fix(intel): fix fcs_client crashed when increased param size 12. 0ca1d8fba fix(layerscape): unlock write access SMMU_CBn_ACTLR 13. b87b02cf1 fix(cpus): workaround for Cortex-A710 erratum 2768515 14. 1cfde8222 fix(cpus): workaround for Cortex-X2 erratum 2768515 15. 377846b65 fix(st): include utils.h to solve compilation error 16. 1cbe42a51 fix(el3_runtime): allow SErrors when executing in EL3 17. 1ee7c8232 fix(cpus): workaround for Neoverse N2 erratum 2743089 18. b10afcce5 fix(cpus): workaround for Cortex-A78 erratum 2772019 19. 31747f057 fix(cpus): workaround for Neoverse V1 erratum 2743093 20. fd37982a1 fix(auth): forbid junk after extensions 21. 72460f50e fix(auth): require at least one extension to be present 22. 06c01b085 fix(libc): properly define SCHAR_MIN 23. 89d85ad0a fix(cpus): workaround for Cortex-A710 erratum 2282622 24. abb8f936f fix(auth): avoid out-of-bounds read in auth_nvctr() 25. f5c51855d fix(auth): properly validate X.509 extensions 26. f9c6301d7 fix(cpus): workaround for Cortex-X2 erratum 2282622 27. 60719e4e0 fix(plat/css): fix invalid redistributor poweroff 28. 00230e37e fix(cpus): workaround for Cortex-A78C erratum 2772121 29. aea4ccf8d fix(cpus): workaround for Cortex-A510 erratum 2684597 If there are commits that we missed or that need to be in the LTS branch, please reach out to us. Thanks.

2 years, 3 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Jan 26, 2023 ⋅ 4pm – 5pm United Kingdom Time Apologies the LTS Update is for this week on 26th January at 4pm GMT Not February session.=====Just a reminder that this week the TF-A Tech Forum is covering a LTS Release update session from the primary maintainers of the TF-A v2.8 LTS branch:Varun WadekarOkash Khawaja Bipin Ravi Thanks AllJoanna========We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org bpeckham(a)google.com mayurvg(a)gmail.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 3 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu Feb 23, 2023 4pm - 5pm (GMT) (tf-a@lists.trustedfirmware.org)

by joanna.farley＠arm.com

This event has been updated Changed: description TF-A Tech Forum Thursday Feb 23, 2023 ⋅ 4pm – 5pm United Kingdom Time Just a reminder that this week the TF-A Tech Forum is covering a LTS Release update session from the primary maintainers of the TF-A v2.8 LTS branch:Varun Wadekar <vwadekar(a)nvidia.com> Okash Khawaja <okash(a)google.com> Bipin Ravi <Bipin.Ravi(a)arm.com>Thanks AllJoanna===============================We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 3 months

1
0
0 0

[TF-A]: Deprecating mbedtls-2.28 support for TF-A 3.0 release

by Govindraj Raja

Hi All, We are in the process of migrating from mbedtls-2.28 support to 3.3 support we plan to deprecate mbedtls-2.28 support for TF-A 3.0 Release but would retain support for both 2.28 and 3.3 for TF-A 2.9 lifetime. There is draft implementation available[1] for code review which cleanups and prepares for mbedtls-3.3 support but retaining backward compatibility for mbedtls-2.28. Please let us know if there any objections to deprecation of mbedtls-2.28 in TF-A 3.0. -- Thanks Govindraj [1]: https://review.trustedfirmware.org/q/topic:%2522mbedtls3.3_support%2522 <https://review.trustedfirmware.org/q/topic:%2522mbedtls3.3_support%2522>

2 years, 3 months

1
0
0 0

Query BL31 version from NWd

by Varun Wadekar

Hi, Happy new year! For NVIDIA Tegra platforms, we need the capability to query the BL31 version (e.g. 2.7, 2.8, 2.8.x) from the NWd at runtime. I could not find an FID that returns this value. I propose we introduce a new runtime service in bl31 that returns the version_string to the NWd to support this requirement. Thoughts? -Varun

2 years, 3 months

8
18
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 382954: Concurrent data access violations (MISSING_LOCK) /plat/mediatek/drivers/spm/mt8188/constraints/mt_spm_rc_cpu_buck_ldo.c: 173 in spm_get_status_rc_cpu_buck_ldo() ________________________________________________________________________________________________________ *** CID 382954: Concurrent data access violations (MISSING_LOCK) /plat/mediatek/drivers/spm/mt8188/constraints/mt_spm_rc_cpu_buck_ldo.c: 173 in spm_get_status_rc_cpu_buck_ldo() 167 dest = (struct constraint_status *)st->value; 168 do { 169 if (dest == NULL) { 170 break; 171 } 172 if (st->type == CONSTRAINT_GET_VALID) { >>> CID 382954: Concurrent data access violations (MISSING_LOCK) >>> Accessing "dest->is_valid" without holding lock "spm_lock". Elsewhere, "constraint_status.is_valid" is accessed with "spm_lock" held 5 out of 6 times. 173 dest->is_valid = cpubuckldo_status; 174 } else if (st->type == CONSTRAINT_COND_BLOCK) { 175 dest->is_cond_block = 0; 176 } else if (st->type == CONSTRAINT_GET_ENTER_CNT) { 177 if (st->id == MT_RM_CONSTRAINT_ID_ALL) { 178 dest->enter_cnt += cpubuckldo_enter_cnt; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

2 years, 3 months

1
0
0 0

Post-boot loading of OP-TEE

by Jens Wiklander

Hi, The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way of post-boot loading OP-TEE by the Linux kernel with signature verification in the normal world only. This has previously been discussed in this mail thread [2] about half a year ago. Ultimately, it was concluded that this should in principle be accepted upstream as a platform choice to allow this or not. There are concerns that what we have in upstream TF-A should serve as good examples, and trusting the normal world to verify secure world software might not meet that criterion. There are also concerns about adding signature verification to BL31 Leaving the secure world wide open until the Linux kernel has been able to successfully load and verify an OP-TEE binary seems very risky. Even if it's claimed that the normal world can be trusted at this point, we're still giving up a critical level of defense without a good reason. I've started to review [1], but it should not be accepted for merging without support and approval from other maintainers. I would like to explore other options in this mail thread. In [2] it was suggested that a remnant of bl2 could be kept to verify OP-TEE before starting to execute it. This could be taken one step further and load a limited OP-TEE at boot which later is updated live, almost like what's discussed in [3]. This should minimize the impact on TF-A and also leave OP-TEE in charge of accepting an update instead of a divided responsibility between the normal world and TF-A. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635 [2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.… [3] https://github.com/OP-TEE/optee_os/issues/5699 Thanks, Jens

2 years, 4 months

3
3
0 0

New vulnerability: Out-of-bounds read in TF-A X.509 parser

by Sandrine Bailleux

Hello everyone, A new security vulnerability has been identified in TF-A X.509 parser, used for trusted boot in BL1 and BL2. Please note that this vulnerability is *not* exploitable in TF-A upstream code. Only downstream code might be affected under specific circumstances. The security advisory has been published in TF-A documentation and has all the details: https://trustedfirmware-a.readthedocs.io/en/latest/security_advisories/secu… Patches to fix the identified bugs have already been merged in TF-A tree. The advisory lists the relevant patches. I would like to thank Demi Marie Obenour from Invisible Things Lab for responsibly disclosing this security vulnerability to TrustedFirmware.org, for providing patches to fix the identified bugs and further harden the X.509 parser, for providing a detailed impact analysis and for helping put this security advisory together. Best regards, Sandrine Bailleux, on behalf of TF-A security team.

2 years, 4 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been updated with a note: "Correcting the deletion of the wrong Techforum." Changed: time TF-A Tech Forum Thursday Jan 26, 2023 ⋅ 4pm – 5pm United Kingdom Time We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Reply for tf-a(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

1
0
0 0

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

by joanna.farley＠arm.com

This event has been canceled with a note: "No topic this week. Cancelling. Joanna" TF-A Tech Forum Thursday Jan 26, 2023 ⋅ 4pm – 5pm United Kingdom Time We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   Guests marek.bykowski(a)gmail.com okash.khawaja(a)gmail.com tf-a(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

2 years, 4 months

1
0
0 0

TF-A Tech Forum Sessions Jan/Feb

by Joanna Farley

Hi all, With the start of the new year I’m looking to see what TF-A Techforums should cover over the next few sessions. As folks may know these are held every two weeks on a Thursday at 4pm GMT. If you need an invite do reach out to me. If folks have anything they would like to present to the TF-A community please do reach out to me as we often need topics. If we don’t have anything to present on upcoming sessions I will cancel the sessions the day before they are due to be held. Currently I tentatively have the following for the first 4 sessions which will be confirmed nearer the dates: * 12th January – No topic * 26th January – LTS Update * 9th February – No topic * 23rd February - Tech talk for PSCI OS-initiated mode Thanks Joanna

2 years, 4 months

1
2
0 0

Runtime loading of SEL-1

by Jeffrey Kardatzke

Hello, I'm working on a project for ChromeOS where we would like to be able to load the BL32 payload (OpTee) for SEL-1 after the linux kernel has booted rather than during the usual BL32 stage. We would do this via an SMC we would add which would take the OpTee image from linux and then have EL3 load it and perform the init for SEL-1 at that time. The reasoning behind this is that it's much easier to update the rootfs than the FW on our devices, and we can still ensure the integrity of the OpTee image if we load it early enough after the kernel boots. The main questions I have are if there are any issues people would be aware of by loading it after linux boots rather than during the usual BL32 stage? And I would definitely want to upstream this work if it's something we can do. Thanks, Jeffrey Kardatzke Google, Inc.

2 years, 4 months

7
14
1 0

Question about using rme for smmuv3

by Chenxu Wang

Hi all, I test the SMMUv3 on FVP_Base_RevC-2xAEMvA_11.20_15, and my TF-A is the branch "arm_cca_v0.3". When I boot my FVP, I set the following commands: -C pci.pci_smmuv3.mmu.SMMU_ROOT_IDR0=3 \ -C pci.pci_smmuv3.mmu.SMMU_ROOT_IIDR=0x43B \ -C pci.pci_smmuv3.mmu.root_register_page_offset=0x20000 \ -C cluster0.rme_support_level=2 \ -C cluster1.rme_support_level=2 \ Based on the FVP manual, the SMMU base is 0x2b40_0000, and I think the SMMU Root Control Page should be 0x2b42_0000. Thus, I add the mapping to this region in plat_arm_mmap[], as: MAP_REGION_FLAT(0x2b420000,(0x2b430000-0x2b420000),MT_MEMORY | MT_RW |MT_ROOT) Then I try to access the SMMU_ROOT_IDR0 register in TF-A. Based on the manual, its offset is 0x0, so I read 0x2b42_0000. However, it returns 0x0, which is not what I configured in the boot commands (I think it should be 0x3). Can someone tell me the reason for this? Sincerely, WANG Chenxu

2 years, 5 months

2
3
0 0

TF-A Tech-Forum Agenda for Thursday 15-Dec-22 at 4pm BST

by Bipin Ravi

Topic: QEMU Support in TF-A OpenCI Presented by: Harrison Mutai Agenda: 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. * 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. [1] Supporting QEMU in OpenCI - TF-A - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…> ================================================= 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…> Thanks & best regards, --Bipin Ravi

2 years, 5 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 382272: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/xilinx/common/ipi_mailbox_service/ipi_mailbox_svc.c: 78 in ipi_smc_handler() ________________________________________________________________________________________________________ *** CID 382272: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /plat/xilinx/common/ipi_mailbox_service/ipi_mailbox_svc.c: 78 in ipi_smc_handler() 72 uint32_t is_secure; 73 74 ipi_local_id = x1 & UNSIGNED32_MASK; 75 ipi_remote_id = x2 & UNSIGNED32_MASK; 76 77 if ((GET_SMC_OEN(smc_fid) >= OEN_TAP_START) && >>> CID 382272: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "((smc_fid >> 24U) & 0x3fU) <= 63U" is always true regardless of the values of its operands. This occurs as the logical second operand of "&&". 78 (GET_SMC_OEN(smc_fid) <= OEN_TOS_END)) { 79 is_secure = 1; 80 } else { 81 is_secure = 0; 82 } 83 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

2 years, 5 months

1
0
0 0

Upcoming "Stricter ASN.1 certificate parsing" patches

by Sandrine Bailleux

Hello everyone, I'd like to draw your attention on the following patch stack (contribution from Demi Marie Obenour, thank you!): https://review.trustedfirmware.org/q/owner:demiobenour%2540gmail.com+is:open These patches refactor the X.509 certificate parser leveraged by the trusted boot implementation in TF-A, such that the parser more closely follows the X.509 format specification [1] and ASN.1/DER encoding rules [2]. In a nutshell, this means that the X.509 parser is now stricter. Some ill-formatted certificates which TF-A would have previously accepted are now rejected. All trusted boot tests in the TF-A OpenCI have passed with these patches but I realize that this does not cover all platforms and use cases. Thus, I'd like to allow time for all platform maintainers that wish it to conduct their own testing and report any issue they're seeing on the mailing list. If we don't hear anything by end of Wednesday (14/12), we'll merge the patches. Best regards, Sandrine [1] See RFC5280, https://datatracker.ietf.org/doc/html/rfc5280 [2] ITU-T X.690, https://www.itu.int/ITU-T/studygroups/com10/languages/X.690_1297.pdf

2 years, 5 months

1
0
0 0

[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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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

2 years, 6 months

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?

2 years, 6 months

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

2 years, 7 months

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

2 years, 7 months

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

2 years, 7 months

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

2 years, 7 months

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

2 years, 7 months

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

2 years, 7 months

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

2 years, 7 months

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

2 years, 7 months

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

2 years, 7 months

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

2 years, 7 months

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

2 years, 7 months

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.

2 years, 7 months

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

2 years, 7 months

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…

2 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. 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…

2 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. 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…

2 years, 8 months

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

2 years, 8 months

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)

2 years, 8 months

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

2 years, 8 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

2 years, 8 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

2 years, 8 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…

2 years, 8 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

2 years, 8 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

2 years, 8 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…

2 years, 8 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

2 years, 8 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

2 years, 8 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

2 years, 9 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

2 years, 9 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

2 years, 9 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 >

2 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A