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