- TF-A - lists.trustedfirmware.org

by Joanna Farley

Hi Varun, The Arm security support pages provides official responses to questions related to security vulnerabilities. [https://developer.arm.com/support/arm-security-updates] Trustedfirmware.org provides Security Centre pages covering the security incident handling and vulnerability disclosure process for hosted projects. [https://developer.trustedfirmware.org/w/collaboration/security_center/] You can find information regarding Nailgun on the following Arm security support FAQ page [https://developer.arm.com/support/arm-security-updates/speculative-processo…]. If you have further questions then please email arm-security(a)arm.com<mailto:arm-security@arm.com> as mentioned in the Arm security support pages. Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Varun Wadekar <vwadekar(a)nvidia.com> Date: Monday, 28 September 2020 at 21:53 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Nailgun Hi, Recently, I learned about Nailgun [1] – leak information by snooping across privilege boundaries with the help of CoreSight. The proof of concept uses Raspberry Pi3 (uses Cortex A-53 CPUs) platform to demonstrate the exploit. Has anyone reviewed this attack and does it affect other Arm v8 CPUs too? Do we have support in TF-A to disable CoreSight to mitigate against such attacks? Are there any other mitigations against this attack? -Varun [1] https://github.com/ningzhenyu/nailgun

4 years, 8 months

2
1
0 0

TF-A LTS wiki page

by Varun Wadekar

Hello team, After the recent discussion in the tech forums for the need of a LTS release, I have create a wiki page [1] on tf.org to discuss how we should move forward. The page is expected to be a "live" document and the intention is to allow the community to capture current problems and expectations from the LTS version. Request you to review the page and provide feedback. Thanks, -Varun [1] https://developer.trustedfirmware.org/w/tf_a/lts_proposal/

4 years, 8 months

1
0
0 0

Re: [TF-A] BL31 as bootloader

by Alexei Fedorov

Hi Ravi, Have you tried to use RESET_TO_BL31 build option for your platform? Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of rkohli2000 gmail via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 07 October 2020 17:01 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] BL31 as bootloader Hi, I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can specify this container image with both bl31.bin and a separate custom app at a give flash address. This is without any security requirements or dependencies. Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point 0x80020000 address ? Thanks in advance. Ravi -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 8 months

2
1
0 0

BL31 as bootloader

by rkohli2000 gmail

Hi, I'm a new user and sorry for some basic TF-A questions. Any guidance is appreciated. I'm am able boot the TF-A bl31.bin image itself on my i.MX8QM MEK platform without using u-boot. I can use the imx-mkimage tool to create a flash or eMMC bootable image (flash.bin). Here, I can specify this container image with both bl31.bin and a separate custom app at a give flash address. This is without any security requirements or dependencies. Can I use the T-FA bl31.bin image to act as a first stage bootloader (without u-boot) and then launch a "custom" bare metal app for Cortex-A53 (for example) on the i.MX8QM at the given (BL33) entry point 0x80020000 address ? Thanks in advance. Ravi

4 years, 8 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 8th October 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 8th October 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * Measured Boot Support in TF-A * Presented by Alexei Fedorov and Javier Almansa Sobrino * Update on the support for Measured Boot in TF-A along with an overview of test cases for integration with a TPM service * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. Thanks Joanna

4 years, 9 months

1
0
0 0

TF-A image construction

by rkohli2000 gmail

Hi, Sorry for the wide distribution and if this isn't the appropriate board. I'm interested in TF-A image construction for the i.MX8QM SoC platform and basic image construction instructions. I'd like to understand how to deploy a user application for the Cortex-A53 core and flash image construction. For example, how to deploy BL31.bin and launch a user app for the platform and what does the following TF-A console log imply for user apps: INFO: Entry point address = 0x80020000 INFO: SPSR = 0x3c9 Any intro info is appreciated. Thanks again. Regards Ravi

4 years, 9 months

1
0
0 0

Re: [TF-A] Query SPD/SPMD behavior with EHF

by Olivier Deprez

Hi Sandeep, Here are a few more details. The reasoning differs when considering pre-Armv8.4 platforms (1) vs Armv8.4 platforms onwards with secure virtualization enabled (2). Case (1): EHF framework unifies EL3 exceptions delivered via different vectors and allows them to be handled in a common way. It is also allowing exception delegation handling to lower secure ELs. This framework although primarily used for RAS, is also used for SDEI and platform EL3 interrupts. EL3's role in this case is about trapping and routing the event to appropriate the component (when the interrupt/exception is not handled solely at EL3). The interoperability between EHF and a Trusted OS is not accurately defined apart from this guidance in EHF documentation: "In order for S-EL1 software to handle Non-secure interrupts while having EHF enabled, the dispatcher must adopt a model where Non-secure interrupts are received at EL3, but are then synchronously handled over to S-EL1." Until then for the specific RAS handling scenario, this was delegated to a StandaloneMM partition running at S-EL0 (through the SPM-MM implementation) and not necessarily delegated to a TOS. In order to better help you, we would need more information on the scenario you intend to achieve, and the environment (Arm architecture version and extensions, GIC version). Or maybe your question was out of curiosity for the longer term approach (2) as described below? Case (2): As a general rule, it is preferred that EL3 reduces its footprint and minimises platform specific handling code. EHF framework would most probably not be enabled at all. The priority logic provided by the GIC PMR register to mask NS interrupts cannot really work as before because all of trusted EL3/S-EL2 and untrusted S-EL1 SPs can manipulate this register. Any secure/non-secure interrupt triggered while running SEL1/SEL0 is trapped first by the S-EL2 firmware (or the so-called SPMC). This translates into SCR_EL3.FIQ/IRQ=0 in the secure world. Group1NS interrupts are redirected to SPMD for routing to NWd. A Group0 interrupt is possibly redirected to a platform driver into an S-EL1 secure partition (e.g. a RAS handling service). Hence it does no longer hold true that Group0 interrupts are necessarily qualified as "EL3 interrupts". It is still possible to redirect Group0 interrupts from S-EL2 to EL3 and be handled there, but as said, this is a less preferred approach. Either way when NWd runs (with SCR_EL3.FIQ=1/IRQ=0), a Group1S/Group0 secure interrupt is trapped at EL3 and routed to SPMD then SPMC. The SPMC can take the decision to resume the secure partition which registered the corresponding secure INTID. This design does mean that SDEI interrupt handling would need SPMC and BL31 collaboration and this is something we are working on. Hope this helps. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 28 September 2020 14:01 To: Sandeep Tripathy; Soby Mathew Cc: tf-a(a)lists.trustedfirmware.org; nd Subject: Re: [TF-A] Query SPD/SPMD behavior with EHF Hi Sandeep, Your question is very valid and we're discussing options internally. We will come back to you with a consolidated answer shortly. Regards, Olivier. ________________________________________ From: Sandeep Tripathy Sent: Monday, September 28, 2020 05:28 To: Soby Mathew Cc: Dan Handley; tf-a(a)lists.trustedfirmware.org; nd; Olivier Deprez Subject: Re: [TF-A] Query SPD/SPMD behavior with EHF Thanks Soby and Dan for confirmation on TSPD. I can see a few more gaps in the related area. "The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC i.e. any execution context for that matter ". This should apply to all SPDs including SPMD. However I learned from @Oliver that SPMD/SPMC design traps FIQs to S_EL2. In that case a RAS interrupt can be masked by S_EL2 software (eg: Hafnium). Probably by design it will be ensured that S_EL2 will never mask the physical FIQ ? S_EL2 FIQ handler will exit to EL3/SPMD by SMC call. And depending on the pending interrupt type either it can exit to NWd OR invoke el3 fiq vector handler synchronously ? Are there limitations if we trap fiq to EL3 instead ? Thanks Sandeep On Fri, Sep 18, 2020 at 6:26 PM Soby Mathew <Soby.Mathew(a)arm.com> wrote: > > Hi Sandeep > > > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECUE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC). > > But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ. > > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > > This is my understanding from the code please confirm if this is correct. > > The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC. Hence the usage of GIC PMR to mask the NS interrupts. As Dan says, the TSP_NS_INTR_ASYNC_PREEMPT predates the EHF design and it seems there is a problem as you describe. > > > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > > This is my understanding from the code please confirm if this is correct. > > You are right. Routing model manipulation is not required when EL3 interrupts are present as GIC PMR manipulation should take care of the required behaviour for yielding vs atomic SMC. You also need to ensure it works as expected when EL3 interrupts are not enabled and when EHF is disabled. > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > > Tripathy via TF-A > > Sent: 17 September 2020 16:53 > > To: Dan Handley <Dan.Handley(a)arm.com> > > Cc: tf-a(a)lists.trustedfirmware.org > > Subject: Re: [TF-A] Query TSPD behavior with EHF > > > > Hi Dan, > > I am not sure if this is mentioned anywhere in any documents but I think > > EHF handlers should be able to preempt all execution contexts at lower ELs > > and lower ELs should never be able to mask such interrupts. > > If the behavioral expectation is set the implementation can be fixed. > > > > Thanks > > Sandeep > > > > On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A <tf- > > a(a)lists.trustedfirmware.org> wrote: > > > > > > A correction... > > > > > > > -----Original Message----- > > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan > > > > Handley via TF-A > > > > Sent: 17 September 2020 15:14 > > > > > > > > > > > > I want to handle something similar in OP-TEED along with EHF > > > > > > depending on > > > > > what is the expected behavior. > > > > > > > > > > Hmm, I thought OP-TEED was more like the > > TSP_NS_INTR_ASYNC_PREEMPT=0 > > > > case, where NS interrupts are routed to S-EL1 while processing a > > > > yielding SMC in S- EL1? Perhaps that's a better TSPD config for you to > > follow? > > > > > > > Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are > > routed to EL3 first, but the TSPD re-enables NS interrupts before handing > > over to the TSP to handle yielding calls, via a call to > > ehf_allow_ns_preemption. > > > > > > > Right, that is the case for yielding SMC handling where both NS interrupts > > and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context. > > But I would expect the same routing model even for 'Fast SMC' unlike what is > > happening in TSPD. > > > > > Dan. > > > > > > -- > > > TF-A mailing list > > > TF-A(a)lists.trustedfirmware.org > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 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. 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 362943: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 362943: Insecure data handling (TAINTED_SCALAR) /common/fdt_fixup.c: 437 in fdt_adjust_gic_redist() 431 432 /* 433 * The redistributor is described in the second "reg" entry. 434 * So we have to skip one address and one size cell, then another 435 * address cell to get to the second size cell. 436 */ >>> CID 362943: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "sc * 4" to a tainted sink. 437 return fdt_setprop_inplace_namelen_partial(dtb, offset, "reg", 3, 438 (ac + sc + ac) * 4, 439 val, sc * 4); ** CID 362942: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /common/fdt_fixup.c: 428 in fdt_adjust_gic_redist() ________________________________________________________________________________________________________ *** CID 362942: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /common/fdt_fixup.c: 428 in fdt_adjust_gic_redist() 422 } 423 424 if (sc == 1) { 425 redist_size_32 = cpu_to_fdt32(nr_cores * gicr_frame_size); 426 val = &redist_size_32; 427 } else { >>> CID 362942: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "nr_cores * gicr_frame_size" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 428 redist_size_64 = cpu_to_fdt64(nr_cores * gicr_frame_size); 429 val = &redist_size_64; 430 } 431 432 /* 433 * The redistributor is described in the second "reg" entry. ** CID 362941: Integer handling issues (BAD_SHIFT) /mbedtls/library/bignum.c: 1713 in mbedtls_int_div_int() ________________________________________________________________________________________________________ *** CID 362941: Integer handling issues (BAD_SHIFT) /mbedtls/library/bignum.c: 1713 in mbedtls_int_div_int() 1707 * Normalize the divisor, d, and dividend, u0, u1 1708 */ 1709 s = mbedtls_clz( d ); 1710 d = d << s; 1711 1712 u1 = u1 << s; >>> CID 362941: Integer handling issues (BAD_SHIFT) >>> In expression "u0 >> 64UL - s", right shifting by more than 63 bits has undefined behavior. The shift amount, "64UL - s", is 64. 1713 u1 |= ( u0 >> ( biL - s ) ) & ( -(mbedtls_mpi_sint)s >> ( biL - 1 ) ); 1714 u0 = u0 << s; 1715 1716 d1 = d >> biH; 1717 d0 = d & uint_halfword_mask; 1718 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 9 months

1
0
0 0

STM32MP1: Adding TF-A causes kernel errors

by Jan Kiszka

Hi Yann, not sure if TF-A is the one to blame, but it's the variable that triggers the following on the STM32MP15x eval board for me. I think I'm following tfa/docs/plat/stm32mp1.rst and u-boot/doc/board/st/stm32mp1.rst correctly. Working: - U-Boot 2020.07, stm32mp15_basic_defconfig - Linux 5.9-rc7 (or 5.4.x), defconfig [ 0.000000] Memory: 815540K/917500K available (13312K kernel code, 1800K rwdata, 5452K rodata, 2048K init, 407K bss, 36424K reserved, 65536K cma-reserved, 196604K highmem) Failing: - TF-A 2.3, PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 \ AARCH32_SP=sp_min STM32MP_SDMMC=1 STM32MP_EMMC=1 STM32MP_RAW_NAND=1 \ STM32MP_SPI_NAND=1 STM32MP_SPI_NOR=1 DTB_FILE_NAME=stm32mp157c-ev1.dtb - U-Boot 2020.07, stm32mp15_trusted_defconfig - Linux as above [ 0.000000] Memory: 881076K/917500K available (13312K kernel code, 1800K rwdata, 5452K rodata, 2048K init, 407K bss, 4294938184K reserved, 65536K cma-reserved, 262140K highmem) which causes issues like [ 0.047215] BUG: Bad page state in process swapper/0 pfn:fa000 [ 0.047236] page:(ptrval) refcount:0 mapcount:-128 mapping:00000000 index:0x1 pfn:0xfa000 [ 0.047249] flags: 0x80000000() CMA [ 0.047273] raw: 80000000 e7f29004 e7f49004 00000000 00000001 0000000b ffffff7f 00000000 [ 0.047281] page dumped because: nonzero mapcount [ 0.047287] Modules linked in: [ 0.047305] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc7 #1 [ 0.047314] Hardware name: STM32 (Device Tree Support) [ 0.047358] [<c0311708>] (unwind_backtrace) from [<c030b88c>] (show_stack+0x10/0x14) [ 0.047384] [<c030b88c>] (show_stack) from [<c0718a40>] (dump_stack+0xc8/0xdc) [ 0.047408] [<c0718a40>] (dump_stack) from [<c047b3c8>] (bad_page+0xdc/0x10c) [ 0.047426] [<c047b3c8>] (bad_page) from [<c047c060>] (__free_pages_ok+0x2e8/0x36c) [ 0.047447] [<c047c060>] (__free_pages_ok) from [<c1623a80>] (init_cma_reserved_pageblock+0x58/0x68) [ 0.047469] [<c1623a80>] (init_cma_reserved_pageblock) from [<c16266c8>] (cma_init_reserved_areas+0x170/0x1c8) [ 0.047491] [<c16266c8>] (cma_init_reserved_areas) from [<c0301ef8>] (do_one_initcall+0x54/0x22c) [ 0.047513] [<c0301ef8>] (do_one_initcall) from [<c160102c>] (kernel_init_freeable+0x188/0x1ec) [ 0.047537] [<c160102c>] (kernel_init_freeable) from [<c0f4a340>] (kernel_init+0x8/0x118) [ 0.047559] [<c0f4a340>] (kernel_init) from [<c03001a8>] (ret_from_fork+0x14/0x2c) [ 0.047570] Exception stack(0xe68b7fb0 to 0xe68b7ff8) [ 0.047584] 7fa0: 00000000 00000000 00000000 00000000 [ 0.047600] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 0.047614] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 0.047624] Disabling lock debugging due to kernel taint Still, the system boots, and I can login. That reserved value the kernel finds is obviously off. Does it come from TF-A, is U-Boot causing this in the presence of TF-A, or is the kernel itself getting it wrong? Or am I missing some switch that is not in the kernel defconfig? Thanks, Jan

4 years, 9 months

2
5
0 0

Re: [TF-A] Tests to verify BP_OPTION

by Alexei Fedorov

Hi, tf-a-tests\tftf\tests\extensions\pauth\test_pauth.c will test fvp-pauth-pac-ret-leaf-sdei,fvp-pauth-standard:fvp-tftf-fip.tftf-aemv8a.8_5-debug fvp-pauth-pac-ret-leaf-tsp-sdei,fvp-pauth-standard:fvp-tftf-fip.tftf-aemv8a.8_5-debug CI configurations. Alexei Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Kalyani Chidambaram Vaidyanathan via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 23 September 2020 18:25 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Tests to verify BP_OPTION Hi, Is there any test to verify the BP_OPTION feature set to “pac-ret+leaf” ? When BRANCH_PROTECTION is set to “3”, BP_OPTION is set to “pac-ret+leaf”. Reference code - https://github.com/ARM-software/arm-trusted-firmware/blob/master/Makefile Thanks, Kalyani

4 years, 9 months

2
2
0 0

a80x0_mcbin doesn't build with recommended mv-ddr-marvell

by Jan Kiszka

Hi all, docs/plat/marvell/armada/build.rst says that you should use branch mv_ddr-armada-atf-mainline from [1]. But that no longer works with tf-a master. The mv-ddr-devel branch builds fine (didn't run the result, though). make CROSS_COMPILE=aarch64-linux-gnu- PLAT=a80x0_mcbin \ USE_COHERENT_MEM=0 MV_DDR_PATH=.../mv-ddr-marvell/ \ SCP_BL2=.../mrvl_scp_bl2.img Are there plans to update the tf-a doc or rather refresh that branch? Jan [1] https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git

4 years, 9 months

2
2
0 0

Nailgun

by Varun Wadekar

Hi, Recently, I learned about Nailgun [1] - leak information by snooping across privilege boundaries with the help of CoreSight. The proof of concept uses Raspberry Pi3 (uses Cortex A-53 CPUs) platform to demonstrate the exploit. Has anyone reviewed this attack and does it affect other Arm v8 CPUs too? Do we have support in TF-A to disable CoreSight to mitigate against such attacks? Are there any other mitigations against this attack? -Varun [1] https://github.com/ningzhenyu/nailgun

4 years, 9 months

1
0
0 0

Re: [TF-A] Query SPD/SPMD behavior with EHF

by Olivier Deprez

Hi Sandeep, Your question is very valid and we're discussing options internally. We will come back to you with a consolidated answer shortly. Regards, Olivier. ________________________________________ From: Sandeep Tripathy Sent: Monday, September 28, 2020 05:28 To: Soby Mathew Cc: Dan Handley; tf-a(a)lists.trustedfirmware.org; nd; Olivier Deprez Subject: Re: [TF-A] Query SPD/SPMD behavior with EHF Thanks Soby and Dan for confirmation on TSPD. I can see a few more gaps in the related area. "The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC i.e. any execution context for that matter ". This should apply to all SPDs including SPMD. However I learned from @Oliver that SPMD/SPMC design traps FIQs to S_EL2. In that case a RAS interrupt can be masked by S_EL2 software (eg: Hafnium). Probably by design it will be ensured that S_EL2 will never mask the physical FIQ ? S_EL2 FIQ handler will exit to EL3/SPMD by SMC call. And depending on the pending interrupt type either it can exit to NWd OR invoke el3 fiq vector handler synchronously ? Are there limitations if we trap fiq to EL3 instead ? Thanks Sandeep On Fri, Sep 18, 2020 at 6:26 PM Soby Mathew <Soby.Mathew(a)arm.com> wrote: > > Hi Sandeep > > > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECUE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC). > > But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ. > > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > > This is my understanding from the code please confirm if this is correct. > > The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC. Hence the usage of GIC PMR to mask the NS interrupts. As Dan says, the TSP_NS_INTR_ASYNC_PREEMPT predates the EHF design and it seems there is a problem as you describe. > > > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > > This is my understanding from the code please confirm if this is correct. > > You are right. Routing model manipulation is not required when EL3 interrupts are present as GIC PMR manipulation should take care of the required behaviour for yielding vs atomic SMC. You also need to ensure it works as expected when EL3 interrupts are not enabled and when EHF is disabled. > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > > Tripathy via TF-A > > Sent: 17 September 2020 16:53 > > To: Dan Handley <Dan.Handley(a)arm.com> > > Cc: tf-a(a)lists.trustedfirmware.org > > Subject: Re: [TF-A] Query TSPD behavior with EHF > > > > Hi Dan, > > I am not sure if this is mentioned anywhere in any documents but I think > > EHF handlers should be able to preempt all execution contexts at lower ELs > > and lower ELs should never be able to mask such interrupts. > > If the behavioral expectation is set the implementation can be fixed. > > > > Thanks > > Sandeep > > > > On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A <tf- > > a(a)lists.trustedfirmware.org> wrote: > > > > > > A correction... > > > > > > > -----Original Message----- > > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan > > > > Handley via TF-A > > > > Sent: 17 September 2020 15:14 > > > > > > > > > > > > I want to handle something similar in OP-TEED along with EHF > > > > > > depending on > > > > > what is the expected behavior. > > > > > > > > > > Hmm, I thought OP-TEED was more like the > > TSP_NS_INTR_ASYNC_PREEMPT=0 > > > > case, where NS interrupts are routed to S-EL1 while processing a > > > > yielding SMC in S- EL1? Perhaps that's a better TSPD config for you to > > follow? > > > > > > > Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are > > routed to EL3 first, but the TSPD re-enables NS interrupts before handing > > over to the TSP to handle yielding calls, via a call to > > ehf_allow_ns_preemption. > > > > > > > Right, that is the case for yielding SMC handling where both NS interrupts > > and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context. > > But I would expect the same routing model even for 'Fast SMC' unlike what is > > happening in TSPD. > > > > > Dan. > > > > > > -- > > > TF-A mailing list > > > TF-A(a)lists.trustedfirmware.org > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

1
0
0 0

Re: [TF-A] Query SPD/SPMD behavior with EHF

by Sandeep Tripathy

Thanks Soby and Dan for confirmation on TSPD. I can see a few more gaps in the related area. "The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC i.e. any execution context for that matter ". This should apply to all SPDs including SPMD. However I learned from @Oliver that SPMD/SPMC design traps FIQs to S_EL2. In that case a RAS interrupt can be masked by S_EL2 software (eg: Hafnium). Probably by design it will be ensured that S_EL2 will never mask the physical FIQ ? S_EL2 FIQ handler will exit to EL3/SPMD by SMC call. And depending on the pending interrupt type either it can exit to NWd OR invoke el3 fiq vector handler synchronously ? Are there limitations if we trap fiq to EL3 instead ? Thanks Sandeep On Fri, Sep 18, 2020 at 6:26 PM Soby Mathew <Soby.Mathew(a)arm.com> wrote: > > Hi Sandeep > > > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECUE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC). > > But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ. > > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > > This is my understanding from the code please confirm if this is correct. > > The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC. Hence the usage of GIC PMR to mask the NS interrupts. As Dan says, the TSP_NS_INTR_ASYNC_PREEMPT predates the EHF design and it seems there is a problem as you describe. > > > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > > This is my understanding from the code please confirm if this is correct. > > You are right. Routing model manipulation is not required when EL3 interrupts are present as GIC PMR manipulation should take care of the required behaviour for yielding vs atomic SMC. You also need to ensure it works as expected when EL3 interrupts are not enabled and when EHF is disabled. > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > > Tripathy via TF-A > > Sent: 17 September 2020 16:53 > > To: Dan Handley <Dan.Handley(a)arm.com> > > Cc: tf-a(a)lists.trustedfirmware.org > > Subject: Re: [TF-A] Query TSPD behavior with EHF > > > > Hi Dan, > > I am not sure if this is mentioned anywhere in any documents but I think > > EHF handlers should be able to preempt all execution contexts at lower ELs > > and lower ELs should never be able to mask such interrupts. > > If the behavioral expectation is set the implementation can be fixed. > > > > Thanks > > Sandeep > > > > On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A <tf- > > a(a)lists.trustedfirmware.org> wrote: > > > > > > A correction... > > > > > > > -----Original Message----- > > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan > > > > Handley via TF-A > > > > Sent: 17 September 2020 15:14 > > > > > > > > > > > > I want to handle something similar in OP-TEED along with EHF > > > > > > depending on > > > > > what is the expected behavior. > > > > > > > > > > Hmm, I thought OP-TEED was more like the > > TSP_NS_INTR_ASYNC_PREEMPT=0 > > > > case, where NS interrupts are routed to S-EL1 while processing a > > > > yielding SMC in S- EL1? Perhaps that's a better TSPD config for you to > > follow? > > > > > > > Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are > > routed to EL3 first, but the TSPD re-enables NS interrupts before handing > > over to the TSP to handle yielding calls, via a call to > > ehf_allow_ns_preemption. > > > > > > > Right, that is the case for yielding SMC handling where both NS interrupts > > and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context. > > But I would expect the same routing model even for 'Fast SMC' unlike what is > > happening in TSPD. > > > > > Dan. > > > > > > -- > > > TF-A mailing list > > > TF-A(a)lists.trustedfirmware.org > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

1
0
0 0

When to implement plat_sdei_validate_entry_point?

by Jan Kiszka

Hi, I'm adding basic SDEI support to the zynqmp platform (just private event 0 for now), and I'm wondering what to do with plat_sdei_validate_entry_point(). Looking around what other SDEI implementations did, neither tegra nor the recently added imx8mm implement this and rather rely on the empty stub from plat/common/aarch64/plat_common.c. As zynqmp also pulls in plat/arm/common/arm_common.c and doesn't find any arm_validate_ns_entrypoint, my search started. Is there anything that makes the check for tegra and imx8mm unneeded? Or are they both broken and should better use plat_sdei_validate_entry_point from plat/arm/common/arm_common.c? Thanks, Jan

4 years, 9 months

2
3
0 0

Re: [TF-A] TF-A warm reboot question

by Soby Mathew

Hi Maxim, There could be some terminology mixup that needs to be clarified. These are the typical words related to boot in TF-A: 1. cold boot : This is the first boot after a power cycle. Typically a single CPU is powered up and executed the entire boot flow upto linux 2. Warm boot: The Cold boot has completed and transitioned into Linux kernel and then the kernel invokes PSCI_CPU_ON to power up the secondary CPUs. This is the CPU `hotplug` operation from linux side. The figure you referred to mentions these boot scenarios. Now reboot is system reset + cold boot. Ideally if QEMU has to support reboot, it needs to be able to reset the system (CPUs and peripherals) from software. The flow you suggest for QEMU could work but if the CPU and the peripherals are not reset properly, you could encounter errors later on because software could assume reset values for some registers and hence may not initialize it. Also there are registers that are 1 time write and cannot be written to again without proper reset cycle, and these could problems during execution. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Maxim > Uvarov via TF-A > Sent: 24 September 2020 13:27 > To: Maxim Uvarov <maxim.uvarov(a)linaro.org> > Cc: tf-a(a)lists.trustedfirmware.org; Ilias Apalodimas > <ilias.apalodimas(a)linaro.org>; Arnd Bergmann <arnd(a)linaro.org> > Subject: Re: [TF-A] TF-A warm reboot question > > sorry, wrong email thread. > > Another way around is to not support "hot reset" in ATF, but make qemu > reboot is implement some watchdog for qemu virt platform. That also works > for me with quick implementation with lhe link which I sent in the previous > email. > > Maxim. > > On Thu, 24 Sep 2020 at 15:16, Maxim Uvarov via TF-A <tf- > a(a)lists.trustedfirmware.org> wrote: > > > > I.e. that implementation works for me: > > > https://github.com/muvarov/qemu/commit/f5e3fb83170613a9eed46b87358 > ab2e > > 37de260a2 > > > > On Mon, 21 Sep 2020 at 18:16, Maxim Uvarov <maxim.uvarov(a)linaro.org> > wrote: > > > > > > Hello, > > > > > > I'm trying to understand why "warm reboot" is not currently > > > implemented in TF-A for qemu targets. I.e. in case of qemu armv8 > > > boot > > > atf->optee->uboot->linux and then reboot, cpu jumps to BL31 > > > qemu_system_reset() function which just calls panic(). I'm wondering > > > why loading images from this stage is not happening? Something > > > similar to bl2_load_images()->load_image() to load uboot and optee > > > os again and run them with bl31_main()? > > > > > > If I understand "CPU reset" spec [1] correctly, warm boot from reset > > > vector in BL31 again to Non-Secure world has to work. > > > > > > [1] > > > https://github.com/ARM-software/arm-trusted- > firmware/blob/master/doc > > > s/design/reset-design.rst > > > > > > Best regards, > > > Maxim. > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

2
1
0 0

Re: [TF-A] TF-A warm reboot question

by Maxim Uvarov

sorry, wrong email thread. Another way around is to not support "hot reset" in ATF, but make qemu reboot is implement some watchdog for qemu virt platform. That also works for me with quick implementation with lhe link which I sent in the previous email. Maxim. On Thu, 24 Sep 2020 at 15:16, Maxim Uvarov via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > I.e. that implementation works for me: > https://github.com/muvarov/qemu/commit/f5e3fb83170613a9eed46b87358ab2e37de2… > > On Mon, 21 Sep 2020 at 18:16, Maxim Uvarov <maxim.uvarov(a)linaro.org> wrote: > > > > Hello, > > > > I'm trying to understand why "warm reboot" is not currently > > implemented in TF-A for qemu targets. I.e. in case of qemu armv8 boot > > atf->optee->uboot->linux and then reboot, cpu jumps to BL31 > > qemu_system_reset() function which just calls panic(). I'm wondering > > why loading images from this stage is not happening? Something > > similar to bl2_load_images()->load_image() to load uboot and optee os > > again and run them with bl31_main()? > > > > If I understand "CPU reset" spec [1] correctly, warm boot from reset > > vector in BL31 again to Non-Secure world has to work. > > > > [1] https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/desig… > > > > Best regards, > > Maxim. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

1
0
0 0

TF-A warm reboot question

by Maxim Uvarov

Hello, I'm trying to understand why "warm reboot" is not currently implemented in TF-A for qemu targets. I.e. in case of qemu armv8 boot atf->optee->uboot->linux and then reboot, cpu jumps to BL31 qemu_system_reset() function which just calls panic(). I'm wondering why loading images from this stage is not happening? Something similar to bl2_load_images()->load_image() to load uboot and optee os again and run them with bl31_main()? If I understand "CPU reset" spec [1] correctly, warm boot from reset vector in BL31 again to Non-Secure world has to work. [1] https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/desig… Best regards, Maxim.

4 years, 9 months

1
1
0 0

Cancelled event with note: TF-A Tech Forum @ Thu 24 Sep 2020 16:00 - 17:00 (BST) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled with this note: "Due to conflicts with Linaro Connect this week we are cancelling this week’s TF-A Techforum on Thursday, 24th September 2020 at 16:00 – 17:00 BST. The next meeting will now be Thursday, 8th October 2020 at 16:00 – 17:00 BST" Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 24 Sep 2020 16:00 – 17:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * marek.bykowski(a)gmail.com * okash.khawaja(a)gmail.com * tf-a(a)lists.trustedfirmware.org Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 9 months

1
0
0 0

Linaro Connect Sessions of Interest

by Don Harbin

Hi All, As Linaro Connect starts tomorrow, here are some pointers to sessions that will be of interest related to trustedfirmware.org. - *PSA Secure Partitions in OP-TEE* - Tuesday, September 22nd (1:25-1:50pm UTC) - Speaker: Miklos Balint - Slides available here <https://static.sched.com/hosted_files/lvc20/9a/LVC20-112_PSA_Secure_Partiti…> - *Trusted Firmware Project update* - Tuesday, Sept. 22nd (2:00-2:25pm UTC) - Spreaders: Matteo Carlini, Shebu Kuriakose - Slides available here <https://static.sched.com/hosted_files/lvc20/1e/LVC20-113-Trusted-Firmware-p…> - *Scalable Security Using Trusted Firmware-M Profiles* - Wednesday September 23rd (11.45am – 12.10pm UTC) - Speakers: Shebu Kuiakose, David Want - Slides available here <https://static.sched.com/hosted_files/lvc20/d0/ScalableSecurityUsingTrusted…> - *Enable UEFI Secure Boot using OP-TEE as Secure Partition* - Thursday September 24th (3.45-4.10pm UTC) - Speakers: Sahil Malhotra, Ilias Apalodimas - *Secure Partition Manager (SEL2 firmware) for Arm A-class devices* - Thursday September 24th (4.15-4.40pm UTC) - Speaker: Olivier Deprez - Slides are available here <https://static.sched.com/hosted_files/lvc20/09/LVC20-305-secure-partition-m…> Some general pointers to sessions of potential interest: - Security related topics can be viewed here - Boot architecture topics can be viewed here As a reminder, sign up for tomorrow's event is at Linaro Connect Registration <https://connect.linaro.org/> and is free, so feel free to forward this information on. :) The overall schedule is available at the same link as registration in case you may be interested in other sessions. Best regards, Don

4 years, 9 months

1
0
0 0

TF-A TechForum 24th Sept Cancelled

by Joanna Farley

Due to conflicts this week I am cancelling this week’s TF-A Techforum on Thursday, 24th September 2020 at 16:00 – 17:00 BST. The next meeting will now be Thursday, 8th October 2020 at 16:00 – 17:00 BST Apologies all. Joanna

4 years, 9 months

1
0
0 0

Re: [TF-A] Tests to verify BP_OPTION

by Alexei Fedorov

Hi, Yes, there are fvp-pauth-pac-ret-leaf-sdei,fvp-pauth-standard:fvp-tftf-fip.tftf-aemv8a.8_5-debug fvp-pauth-pac-ret-leaf-tsp-sdei,fvp-pauth-standard:fvp-tftf-fip.tftf-aemv8a.8_5-debug configs in platform-ci/group/tftf-l2-fvp introduced by https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/5393 Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 17 September 2020 19:18 To: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Tests to verify BP_OPTION <Bump to get this email through> From: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com> Sent: Wednesday, September 16, 2020 11:54 AM To: tf-a(a)lists.trustedfirmware.org Cc: Varun Wadekar <vwadekar(a)nvidia.com> Subject: Tests to verify BP_OPTION Hi, Is there any test to verify the BP_OPTION feature set to “pac-ret+leaf” ? When BRANCH_PROTECTION is set to “3”, BP_OPTION is set to “pac-ret+leaf”. Reference code - https://github.com/ARM-software/arm-trusted-firmware/blob/master/Makefile Thanks, Kalyani

4 years, 9 months

2
2
0 0

Re: [TF-A] Query TSPD behavior with EHF

by Soby Mathew

Hi Sandeep > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECUE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC). > But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ. > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > This is my understanding from the code please confirm if this is correct. The EL3 interrupts (G0 interrupts) should be able to pre-empt Fast SMC. Hence the usage of GIC PMR to mask the NS interrupts. As Dan says, the TSP_NS_INTR_ASYNC_PREEMPT predates the EHF design and it seems there is a problem as you describe. > EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case. > This is my understanding from the code please confirm if this is correct. You are right. Routing model manipulation is not required when EL3 interrupts are present as GIC PMR manipulation should take care of the required behaviour for yielding vs atomic SMC. You also need to ensure it works as expected when EL3 interrupts are not enabled and when EHF is disabled. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > Tripathy via TF-A > Sent: 17 September 2020 16:53 > To: Dan Handley <Dan.Handley(a)arm.com> > Cc: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] Query TSPD behavior with EHF > > Hi Dan, > I am not sure if this is mentioned anywhere in any documents but I think > EHF handlers should be able to preempt all execution contexts at lower ELs > and lower ELs should never be able to mask such interrupts. > If the behavioral expectation is set the implementation can be fixed. > > Thanks > Sandeep > > On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A <tf- > a(a)lists.trustedfirmware.org> wrote: > > > > A correction... > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan > > > Handley via TF-A > > > Sent: 17 September 2020 15:14 > > > > > > > > > > I want to handle something similar in OP-TEED along with EHF > > > > > depending on > > > > what is the expected behavior. > > > > > > > > Hmm, I thought OP-TEED was more like the > TSP_NS_INTR_ASYNC_PREEMPT=0 > > > case, where NS interrupts are routed to S-EL1 while processing a > > > yielding SMC in S- EL1? Perhaps that's a better TSPD config for you to > follow? > > > > > Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are > routed to EL3 first, but the TSPD re-enables NS interrupts before handing > over to the TSP to handle yielding calls, via a call to > ehf_allow_ns_preemption. > > > > Right, that is the case for yielding SMC handling where both NS interrupts > and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context. > But I would expect the same routing model even for 'Fast SMC' unlike what is > happening in TSPD. > > > Dan. > > > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

1
0
0 0

Re: [TF-A] Build failure in OpenCI

by Joanna Farley

FYI we are trying to get the OpenCI to use a different label (Validation-Bot-Review) which is not part our of day to day workflow for patch approvals but standard plugins being used don't seem to support non standard labels so they are working on an alternative approach. Hopefully it will be fixed soon so we don't have to manually remove the OpenCI bot setting on the CR label. Joanna On 18/09/2020, 09:30, "TF-A on behalf of Yann GAUTIER via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Olivier, Thanks for your answer. I was not particularly worried when I saw what the error was. And I understand it can take time to stabilize such infrastructure. It is nice that we can have access to it now. Regards, Yann -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: vendredi 18 septembre 2020 10:22 To: tf-a(a)lists.trustedfirmware.org; Yann GAUTIER <yann.gautier(a)st.com> Subject: Re: Build failure in OpenCI Hi Yann, The OpenCI is under enablement/works, and I think you can safely ignore those CR-1/Verified-1 from the bot. Current CI strategy is still about maintainers applying Allow-CI+1/2 (resulting in Verified+1 on success). Sorry for the trouble it causes presently. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Yann GAUTIER via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 September 2020 09:33 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Build failure in OpenCI Hi, I've pushed some series of patches this morning, but none of them passes the OpenCI builds and tests. For all of them, the error is the same, Lava cannot find a file: http://ci.trustedfirmware.org/job/tf-a-builder//ws/custom_lava_job_definiti…<http://ci.trustedfirmware.org/job/tf-a-builder/ws/custom_lava_job_definitio…> See for example: https://ci.trustedfirmware.org/job/post-build-lava/3941/console Do you know what's wrong with this file? And if it will be corrected soon? Thanks, Yann -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 9 months

1
0
0 0

Re: [TF-A] Build failure in OpenCI

by Olivier Deprez

Hi Yann, The OpenCI is under enablement/works, and I think you can safely ignore those CR-1/Verified-1 from the bot. Current CI strategy is still about maintainers applying Allow-CI+1/2 (resulting in Verified+1 on success). Sorry for the trouble it causes presently. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Yann GAUTIER via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 September 2020 09:33 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Build failure in OpenCI Hi, I’ve pushed some series of patches this morning, but none of them passes the OpenCI builds and tests. For all of them, the error is the same, Lava cannot find a file: http://ci.trustedfirmware.org/job/tf-a-builder//ws/custom_lava_job_definiti…<http://ci.trustedfirmware.org/job/tf-a-builder/ws/custom_lava_job_definitio…> See for example: https://ci.trustedfirmware.org/job/post-build-lava/3941/console Do you know what’s wrong with this file? And if it will be corrected soon? Thanks, Yann

4 years, 9 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A