On Fri, 31 May 2024 at 17:09, Jean-Philippe Brucker
<jean-phili...@linaro.org> wrote:
>
> Hi Gavin,
>
> On Fri, May 31, 2024 at 04:23:13PM +1000, Gavin Shan wrote:
> > I got a chance to try CCA software components, suggested by [1]. However,
> > the edk2
> > is stuck somewhere. I didn't reach to stage of loading guest kernel yet.
> > I'm replying
> > to see if anyone has a idea.
> ...
> > INFO: BL31: Preparing for EL3 exit to normal world
> > INFO: Entry point address = 0x60000000
> > INFO: SPSR = 0x3c9
> > UEFI firmware (version built at 01:31:23 on May 31 2024)
> >
> > The boot is stuck and no more output after that. I tried adding more
> > verbose output
> > from edk2 and found it's stuck at the following point.
> >
> >
> > ArmVirtPkg/PrePi/PrePi.c::PrePiMain
> > rmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c::PlatformPeim
> >
> > #ifdef MDE_CPU_AARCH64
> > //
> > // Set the SMCCC conduit to SMC if executing at EL2, which is typically
> > the
> > // exception level that services HVCs rather than the one that invokes
> > them.
> > //
> > if (ArmReadCurrentEL () == AARCH64_EL2) {
> > Status = PcdSetBoolS (PcdMonitorConduitHvc, FALSE); // The
> > function is never returned in my case
> > ASSERT_EFI_ERROR (Status);
> > }
> > #endif
>
> I'm able to reproduce this even without RME. This code was introduced
> recently by c98f7f755089 ("ArmVirtPkg: Use dynamic PCD to set the SMCCC
> conduit"). Maybe Ard (Cc'd) knows what could be going wrong here.
>
> A slightly reduced reproducer:
>
> $ cd edk2/
> $ build -b DEBUG -a AARCH64 -t GCC5 -p ArmVirtPkg/ArmVirtQemuKernel.dsc
> $ cd ..
>
> $ git clone https://github.com/ARM-software/arm-trusted-firmware.git tf-a
> $ cd tf-a/
> $ make -j CROSS_COMPILE=aarch64-linux-gnu- PLAT=qemu DEBUG=1 LOG_LEVEL=40
> QEMU_USE_GIC_DRIVER=QEMU_GICV3
> BL33=../edk2/Build/ArmVirtQemuKernel-AARCH64/DEBUG_GCC5/FV/QEMU_EFI.fd all
> fip && \
> dd if=build/qemu/debug/bl1.bin of=flash.bin && \
> dd if=build/qemu/debug/fip.bin of=flash.bin seek=64 bs=4096
> $ qemu-system-aarch64 -M virt,virtualization=on,secure=on,gic-version=3 -cpu
> max -m 2G -smp 8 -monitor none -serial mon:stdio -nographic -bios flash.bin
>
Hmm, this is not something I anticipated.
The problem here is that ArmVirtQemuKernel does not actually support
dynamic PCDs, so instead, the PCD here is 'patchable', which means
that the underlying value is just overwritten in the binary image, and
does not propagate to the rest of the firmware. I assume the write
ends up targettng a location that does not tolerate this.
Running ArmVirtQemu or ArmVirtQemuKernel at EL2 has really only ever
worked by accident, it was simply never intended for that. The fix in
question was a last minute tweak to prevent some CVE fixes pushed by
MicroSoft from breaking network boot entirely, and now that the
release has been made, I guess we should revisit this and fix it
properly.
So the underlying issue here is that on these platforms, we need to
decide at runtime whether to use HVC or SMC instructions for SMCCC
calls. This code attempts to record this into a dynamic PCD once at
boot, in a way that permits other users of the same library to simply
hardcode this in the platform definition (given that bare metal
platforms never need this flexibility).
