Fedora Account System
Red Hat Associate
Red Hat Customer
After updating to Fedora 42 I'm not able to boot up kvm/queme VMs/guests that have secure boot enabled. The boot hangs after "Loading initial ramdisk". The following is taken from a fully up-to-date Debian 12 VM. The same VM successfully booted with Fedora 41. Attaching a serial console to the guest delivers: !!!! X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - 00000000 !!!! ExceptionData - 0000000000000011 I:1 R:0 U:0 W:0 P:1 PK:0 SS:0 SGX:0 RIP - 00000000000010F0, CS - 0000000000000038, RFLAGS - 0000000000210046 RAX - 0000000000000000, RCX - 0000000000000501, RDX - 000000007A42BA40 RBX - 00000000000000F0, RSP - 000000007EED3148, RBP - 000000007A9E6900 RSI - 000000007A42BA40, RDI - 0000000000000000 R8 - 000000005C2C9000, R9 - 0000000000000000, R10 - 0000000000000004 R11 - 000000007C3EAB57, R12 - 000000007AE59710, R13 - 000000007C3EAB57 R14 - 000000007AE530A0, R15 - 000000007AE5309A DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 GS - 0000000000000030, SS - 0000000000000030 CR0 - 0000000080010033, CR2 - 00000000000010F0, CR3 - 000000007EC01000 CR4 - 0000000000000668, CR8 - 0000000000000000 DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 GDTR - 000000007E9E1000 0000000000000047, LDTR - 0000000000000000 IDTR - 000000007E24E018 0000000000000FFF, TR - 0000000000000000 FXSAVE_STATE - 000000007EED2DA0 Having a closer look this seems related to the following entry in the release notes: https://fedoraproject.org/wiki/Changes/Edk2Security Additionally there is the following discussion: https://discussion.fedoraproject.org/t/after-upgrading-to-fedora-42-the-system-cant-boot-existing-debian-virtual-machine-installed-in-a-qcow2-disk-image/150536/13 The assumption in the changelog was that all bootloaders shipped in 2024 are fine. That seems not to be the case for current Debian (and it's derivatives) The changelog entry has a "compatibility" section, which tells me that I should simply disable secure boot. That is not an option for all use cases. Disk encryption with TPM is one of those. Secure boot is a must have in such scenarios. In addition: The guest might be a third party VM that is out of the users control So simply changing a fundamental property (like secure boot) might not be allowed / work. Any chance that this additional "NX checking" is reverted until all major distros ship "fixed" bootloaders? Best regards, Florian Reproducible: Always Steps to Reproduce: 1. Try to boot up a kvm/qemu guest with secure boot enabled 2. The bootloader (grub-efi) starts and is able to load the kernel + initrd but freezes after "Loading initial ramdisk..." Actual Results: Freeze of the guest Expected Results: Successful boot of the VM/guest. Additional Information: The change tracking bug: https://bugzilla.redhat.com/show_bug.cgi?id=2346152
https://copr.fedorainfracloud.org/coprs/kraxel/edk2.testbuilds/ Changes: - Turn on EFI_MEMORY_ATTRIBUTE_PROTOCOL by default. - Add page fault handler which will ... (a) fixup page tables if ID or RW faults happen. (b) count those fixups. - If fixups have been needed report the numbers on the console at ExitBootService time. local testing: - debian 12 boots. Needs one fixup. Not reported on the console because that happens after ExitBootService (but before the kernel takes over the page fault handler). It's in the firmware log though. - debian 13 boots without problems. - fedora / rhel-9 / rhel-10 all boot with a single fixup being needed. Grub has a bug in EFI_MEMORY_ATTRIBUTE_PROTOCOL code causing this (see https://issues.redhat.com/browse/RHEL-74341). - rhel-8.10 boots with >20 fixups. - rhel-8.8 does not boot. Not fully clear why. Probably the kernel gets a ID/RW page fault after taking over the page fault handler, but fails to cope.
*** Bug 2354064 has been marked as a duplicate of this bug. ***
*** Bug 2368160 has been marked as a duplicate of this bug. ***
I can confirm that the packages provided above are fixing my problem. Debian 12 is booting up again. Thanks!
FEDORA-2025-7e2a69db6b (edk2-20250523-11.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-7e2a69db6b
https://fedoraproject.org/wiki/Changes/Edk2Security#july_2025_update
FEDORA-2025-7e2a69db6b has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-7e2a69db6b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-7e2a69db6b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-7e2a69db6b (edk2-20250523-11.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.