- TF-A - lists.trustedfirmware.org

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, 3 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, 3 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, 3 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 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, 3 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, 3 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A