[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

question regarding vexpress and aarch64 secure boot

From: Thomas Meyer
Subject: question regarding vexpress and aarch64 secure boot
Date: Mon, 14 Sep 2020 21:58:21 +0200


When trying to boot an linux kernel with

qemu-system-aarch64 -s -S -kernel /path/to/kernel -append
"console=ttyAMA0 loglevel=9 nokaslr" -dtb /path/to/dtb -M vexpress-a15 -cpu 
cortex-a53 -nographic

I do hit the assertion:
qemu-system-aarch64: /builddir/build/BUILD/qemu-4.2.1/hw/arm/boot.c:742: 
do_cpu_reset: Assertion `!info->secure_boot' failed.

which seems to come from this commit:
43118f4351c hw/arm/boot.c (Peter Maydell          2018-03-13  745)              
       /* AArch64 kernels never boot in secure mode */
43118f4351c hw/arm/boot.c (Peter Maydell          2018-03-13  746)              
43118f4351c hw/arm/boot.c (Peter Maydell          2018-03-13  747)              
       /* This hook is only supported for AArch32 currently:
43118f4351c hw/arm/boot.c (Peter Maydell          2018-03-13  748)              
        * bootloader_aarch64[] will not call the hook, and
43118f4351c hw/arm/boot.c (Peter Maydell          2018-03-13  749)              
        * the code above has already dropped us into EL2 or EL1.
43118f4351c hw/arm/boot.c (Peter Maydell          2018-03-13  750)              
43118f4351c hw/arm/boot.c (Peter Maydell          2018-03-13  751)              

So I did try to boot with "-machine secure=off" which makes the kernel
boot (at least a bit...), but it also seems to drop EL3 support in vexpress.c:

        if (!secure) {
            object_property_set_bool(cpuobj, "has_el3", false, NULL);

which triggers arm/cpu.c:

    if (!cpu->has_el3) {
        /* If the has_el3 CPU property is disabled then we need to disable the
         * feature.
        unset_feature(env, ARM_FEATURE_EL3);

my kernel then tries to determine the secure state by issuing a SCM
instruction, which leads to an undefined exception because no EL3 is
available, see arm/target/op_helper.c:

    if (!arm_feature(env, ARM_FEATURE_EL3) &&
        cpu->psci_conduit != QEMU_PSCI_CONDUIT_SMC) {
        /* If we have no EL3 then SMC always UNDEFs and can't be
         * trapped to EL2. PSCI-via-SMC is a sort of ersatz EL3
         * firmware within QEMU, and we want an EL2 guest to be able
         * to forbid its EL1 from making PSCI calls into QEMU's
         * "firmware" via HCR.TSC, so for these purposes treat
         * PSCI-via-SMC as implying an EL3.
         * This handles the very last line of the previous table.
        raise_exception(env, EXCP_UDEF, syn_uncategorized(),

which leads the kernel to call die()

So may question is:
is above assert wrong? Is this a bug?

I think the assert in above commit tries to prevent the boot in secure
state (vs non-secure state/NS), but I think there is a mix-up between secure 
state and EL3

what do you think?

bug or feature?

please be gentle as I'm fairly new to qemu and aarch64 :-)

with kind regards

reply via email to

[Prev in Thread] Current Thread [Next in Thread]