I just reminded myself of the extra fun shim shenanigans going on in Asahi Fedora. I've previously described the Asahi Linux boot chain as:

SecureROM -> iBoot1 -> iBoot2 -> m1n1 stage 1 -> m1n1 stage 2 -> u-boot -> GRUB - > Linux

Which is already amusing enough, but Fedora throws in another twist. To support other platforms with "interesting" secure boot requirements (cough Microsoft-controlled certificates cough), Fedora ships with shim to handle handoff to GRUB and allow users to control their UEFI secure boot keys. But it's even more fun than that, because our installs don't support UEFI variables and instead have a 1:1 mapping between EFI system partitions and OSes, relying on the default removable media boot path.

On an installed Asahi Fedora system, you get this:

EFI
EFI/BOOT
EFI/BOOT/BOOTAA64.EFI
EFI/BOOT/fbaa64.efi
EFI/BOOT/mmaa64.efi
EFI/fedora
EFI/fedora/BOOTAA64.CSV
EFI/fedora/grub.cfg
EFI/fedora/grubaa64.efi
EFI/fedora/mmaa64.efi
EFI/fedora/shim.efi
EFI/fedora/shimaa64.efi
EFI/fedora/gcdaa64.efi

Here, U-Boot runs BOOT/BOOTAA64.EFI, which is a copy of shim. shim is designed to boot grubaa64.efi from the same directory. But since it can't find it there (since it's in fedora), it goes ahead and loads fbaa64.efi instead. That's a fallback app that then goes off searching for bootable OSes, looking for CSV files in every subfolder of EFI. It finds fedora/BOOTAA64.CSV, which is a UTF-16 CSV file that points it to shimaa64.efi. That is, itself, another identical copy of shim, but this time it's booted from the right fedora directory. The fallback app tries to configure this as a boot image in the EFI variables, but since we don't support those, that fails and continues. Then this second fedora/shimaa64.efi runs and finally finds fedora/grubaa64.efi which is the GRUB core image which continues booting.

So, on Fedora Asahi, the boot chain is actually:

SecureROM -> iBoot1 -> iBoot2 -> m1n1 stage 1 -> m1n1 stage 2 -> u-boot -> shim (first copy) -> fallback -> shim (second copy) -> GRUB - > Linux

Every. Time. (Thankfully, these extra steps go fast so it doesn't materially affect boot time; the major bootloader time contributors are kernel/initramfs load time and U-Boot USB init time right now).

The shim stuff is, of course, completely useless for Asahi Linux, since there are no built-in platform keys or any of that UEFI secure boot nonsense; once we do support secure boot, the distro update handoff will be at the m1n1 stage 1/2 boundary, well before any of this stuff, and the UEFI layer might as well use a fixed distro key/cert that will be known to always work, plus the m1n1 stage 2 signing key (which is not going to use UEFI Secure boot, it will be its own simpler thing) would be set at initial install time to whatever the distro needs. But since this mechanism exists to support other platforms, we didn't want to diverge and attempt to "clean this up" further, since that just sets us up for more weird breakage in the future. Blame Microsoft for this extra mess...

But it's even sillier, because this whole UEFI secure boot mechanism isn't supported in Fedora aarch64 at all (the shim isn't actually signed, and GRUB/fallback are signed with a test certificate), so this whole mechanism is actually completely useless on all aarch64 platforms, it only gets built and signed properly on x86, and aarch64 just inherits it 🙃​

In the early Fedora Asahi days I noticed our Kiwi build stuff was dumping the GRUB core image into EFI/BOOT too, which bypassed this fallback mechanism... but also meant that the GRUB core image didn't get updated when GRUB got updated, which is a ticking time bomb. Thankfully we noticed that and got rid of it. So now there's a silly boot chain, but it should be safe for normal distro updates.

(As for the other stuff? mmaa64.efi is the MokManager that is useless to us, and shim.efi is just a copy of shim for some reason, and gcdaa64.efi is just a copy of grub for some reason. No idea why those two exist.)