EDK II OvmfPkg (X86QemuLoadImageLib, QemuLoadKernelImage direct-boot path): With Secure Boot on, a kernel

Impact

With Secure Boot on, a kernel whose signature is not in the allowed database is correctly rejected by image verification - and then loaded anyway, because the code falls back to the legacy loader. The guest boots an unsigned kernel while reporting that Secure Boot is enforcing. Any tenant-isolation or attestation story that rests on guest Secure Boot in a QEMU/KVM GPU environment is simply not true on affected OVMF builds.

Who can reach it

Whoever controls the kernel image or the direct-boot command line for the VM - a tenant with access to their own instance's boot configuration, or an attacker who has compromised the image pipeline. Requires the VM to use QEMU direct kernel boot rather than a normal bootloader.

What to do

Hypervisor-side firmware package update (edk2/OVMF), not a server BIOS flash - update the ovmf/edk2 build on your hosts and restart guests onto the new firmware; no host reboot needed. Config workaround: stop using QEMU direct kernel boot for guests that rely on Secure Boot, and boot through a signed shim/bootloader from a virtual disk instead.

References