Comment 3 for bug 2037100

Thank you for the quality bug report Corey. Sorry it took so long to get back to you, but I've never used this boot method, and I needed to find focused time to figure out what was going on.

It turns out that the relevant change that is impacting you is that we introduced secure-boot enabled images for AArch64 with the Microsoft keys pre-enrolled (/usr/share/AAVMF/AAVMF_*ms.fd) starting in 2021.02-1. virt-install/libvirt now choose the secure boot images by default because of the ordering of descriptors in /usr/share/qemu/firmware. Because you are now booting with secure boot active, the firmware is trying to verify the kernel with Microsoft's keys. Ubuntu kernels are not signed by Microsoft directly - you are required to boot our MS-signed shim first, which will add trust for Canonical-signed binaries. So, the firmware is aborting that boot option and falling back to the EFI Shell.

This is behaving as designed.

You can override this and restore the prior behavior by specifying the non-ms images on the virt-install command line:

--boot loader=/usr/share/AAVMF/AAVMF_CODE.fd,loader_ro=yes,loader_type=pflash

The 2nd part you noted here is that, once the firmware decides to abort the kernel boot and move on to the Shell, the jammy version of the firmware crashes w/ Synchronous Aborts. This was an upstream bug that was fixed in 2023.02 with this commit:

commit 592bf33a29360e8a447ed8b75daefe94c0888642
Author: Michael D Kinney <michael.d.kinney@XXX>
Date: Fri Dec 9 07:53:21 2022 -0800

    ShellPkg/Shell: Do not set end device path if already end

    Update Shell Protocol EfiShellGetMapFromDevicePath() to not
    set the end if the device path if it is already an end of
    entire device path. This removes a write operation that can
    cause failures if the Device Path Protocol is mapped to
    read-only memory. In general Device Path Protocols should not
    be modified unless the API explicitly states that the device
    path is modified.

That's why you see the crash in jammy, but not in 2023.05-1. Since this is the only behavior that is not working as designed, I suggest we limit the scope of this bug to the Shell crash, and mark it Fix Released for releases that have this fix.