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>
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
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
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
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+
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
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
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
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
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…