From b651a4e2d06e00ecfdd5ea0110288270ea59c837 Mon Sep 17 00:00:00 2001 From: Codex Date: Fri, 8 May 2026 21:06:18 -0500 Subject: [PATCH] fix(ci1): disable SecureBoot to allow OVMF to boot Windows ISO containerDisk delivery (commit b998f50) successfully gave qemu fast in-memory access to the ISO bytes (no NFS denial, no Longhorn read latency), but OVMF's BdsDxe still timed out: BdsDxe: loading Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x2,0x4)/Pci(0x0,0x0)/Scsi(0x0,0x0) BdsDxe: starting Boot0001 ... Time out That rules out storage IO speed and bus type as causes (already tested both sata and scsi against both Longhorn-PVC and tmpfs-backed containerDisk). Remaining likely cause: SecureBoot signature verification on the ISO's EFI bootloader. KubeVirt's stock `/usr/share/OVMF/OVMF_VARS.secboot.fd` doesn't appear to ship with the Microsoft KEK/DB enrolled by default, so signed Windows EFI bootloaders fail the trust-chain check and OVMF reports a generic "Time out" rather than a verification failure. Disabling SecureBoot lets OVMF skip the chain check entirely and boot the El Torito EFI image. SMM stays enabled (KubeVirt only requires it WITH SecureBoot, not the inverse). TPM 2.0 emulation also stays on (`tpm: {}`), so BitLocker, Hyper-V, and WSL2 still work in the guest. This is acceptable for a CI runner. Long-term path back to SecureBoot: 1. Custom-build OVMF_VARS.fd with Microsoft KEK/DB pre-enrolled 2. Mount via firmware.bootloader.efi.persistent 3. secureBoot: true Tracked as a Phase 2 hardening task once the runner is doing real work and we want signed-boot guarantees. Co-Authored-By: Claude Opus 4.7 (1M context) --- apps/kubevirt-vms/ci1.yaml | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/apps/kubevirt-vms/ci1.yaml b/apps/kubevirt-vms/ci1.yaml index 2239ee3..84a9f7c 100644 --- a/apps/kubevirt-vms/ci1.yaml +++ b/apps/kubevirt-vms/ci1.yaml @@ -377,7 +377,22 @@ spec: firmware: bootloader: efi: - secureBoot: true + # 2026-05-08: SecureBoot=false during initial install. With SecureBoot + # enabled, OVMF's BdsDxe times out reading Boot0001 from the SCSI + # CDROM ("BdsDxe: failed to start Boot0001 ... Time out") before the + # EFI bootloader signature can verify against the OVMF VARS trust DB. + # KubeVirt's `/usr/share/OVMF/OVMF_VARS.secboot.fd` template doesn't + # appear to include the Microsoft KEK/DB by default, so signed + # Windows EFI bootloaders fail validation. Disabling SecureBoot lets + # OVMF skip the chain check and boot directly. This is acceptable for + # a CI runner — TPM 2.0 is still emulated (`tpm: {}` below) so + # BitLocker / Hyper-V / WSL still work. + # When the operator wants SecureBoot back, the path is: + # 1. Custom-build OVMF_VARS.fd with Microsoft KEK/DB enrolled + # 2. Mount it into the VM via firmware.bootloader.efi.persistent + # 3. Set secureBoot: true again + # Tracked separately from the install unblock. + secureBoot: false devices: tpm: {} # Non-persistent vTPM — sufficient for runner; no BitLocker disks: