Control: tags -1 + patch Following up with test results and a patch for trixie.
On the question earlier in this bug: VMs with only the 2011 keys keep booting the binaries they already have. What fails is the first binary signed only with the 2023 CA. As the Debian wiki explains (https://wiki.debian.org/SecureBoot/CAChanges), the next shim update can only be signed with the current Microsoft UEFI CA. Status as of 2026-10-12: trixie's ovmf 2025.02-8+deb13u1 (and bookworm's 2022.11-6+deb12u2) still ship OVMF_VARS_4M.ms.fd with only the 2011 Microsoft keys: PK Debian UEFI Secure Boot (PK/KEK key) KEK Debian UEFI Secure Boot (PK/KEK key), Microsoft Corporation KEK CA 2011 db Microsoft Windows Production PCA 2011, Microsoft Corporation UEFI CA 2011 forky/sid (2026.08+ds-2), Ubuntu 22.04 to 26.04, Fedora 43, AlmaLinux 9/10 and openSUSE Leap 16.0 all include the 2023 KEK and db certificates. Test (QEMU/KVM, trixie OVMF_CODE_4M.secboot.fd, unmodified trixie genericcloud image). We made a genuine 2023-only shim by removing the 2011 signature from trixie's dual-signed shimx64.efi.signed (shim-signed 1.51~1+deb13u1). The Authenticode hash does not cover the certificate table, so Microsoft's 2023 signature stays valid. A 2011-only cut is the control: varstore shim signed by result trixie .ms template 2011 only boots, SecureBoot=1 (control) trixie .ms template 2023 only BdsDxe: failed to load Boot0001 ...: Access Denied template + 2023 certs (below) 2023 only boots, SecureBoot=1 In an existing Debian guest, shim-signed's preinst should refuse a shim whose signers are not in db and keep the old one (we read this from the script and did not run it). Fresh installs from 2023-only media fail as above. `virsh start --reset-nvram` does not help on trixie, because it copies the same 2011-only template. Patch for trixie: Ubuntu's OvmfPkg-Expand-EnrollDefaultKeys-with-Microsoft-2023-keys.patch (LP: #2146560; the same file is in noble 2024.02-2ubuntu0.9 and questing 2025.02-8ubuntu3.2, which shares trixie's upstream base) applies cleanly on top of the 2025.02-8+deb13u1 series without changes: https://git.launchpad.net/ubuntu/+source/edk2/plain/debian/patches/OvmfPkg-Expand-EnrollDefaultKeys-with-Microsoft-2023-keys.patch?h=import/2025.02-8ubuntu3.2 sha256 a0edc3c91100c278ffd9c68fcba0777474c83df26446688bfe2e3dd27355b4fb The rest of the debdiff is one line appended to debian/patches/series: OvmfPkg-Expand-EnrollDefaultKeys-with-Microsoft-2023-keys.patch and a changelog entry: edk2 (2025.02-8+deb13u2) trixie; urgency=medium * Add the Microsoft 2023 KEK and db certificates to EnrollDefaultKeys, so the pre-enrolled .ms varstores include them (Closes: #1134793). Patch taken from Ubuntu (LP: #2146560). With it, `debian/rules build-ovmf` in a debian:13 container (about 7 minutes) produces an OVMF_VARS_4M.ms.fd with: PK Debian UEFI Secure Boot (PK/KEK key) KEK Debian UEFI Secure Boot (PK/KEK key), Microsoft Corporation KEK CA 2011, Microsoft Corporation KEK 2K CA 2023 db Microsoft Windows Production PCA 2011, Microsoft Corporation UEFI CA 2011, Microsoft UEFI CA 2023, Microsoft Option ROM UEFI CA 2023, Windows UEFI CA 2023 With the rebuilt OVMF_CODE_4M.secboot.fd and this template, the same image boots both the 2023-only and the 2011-only shim with SecureBoot=1. We only built the x86 OVMF target. Existing VMs: the workaround earlier in this bug (`virt-fw-vars --enroll-redhat --microsoft-kek all`) works, but it also replaces the VM's PK and Debian KEK with Red Hat's "Red Hat Secure Boot (PK/KEK key 1)". To keep the Debian PK and add only the 2023 certificates with trixie's own python3-virt-firmware 24.11 (shut the VM down and back up its NVRAM file first): C=/usr/lib/python3/dist-packages/virt/firmware/certs MS=77fa9abd-0359-4d32-bd60-28f4e78f784b virt-fw-vars --inplace /var/lib/libvirt/qemu/nvram/VM_VARS.fd \ --add-kek $MS $C/MicrosoftCorporationKEK2KCA2023.pem \ --add-db $MS $C/WindowsUEFICA2023.pem \ --add-db $MS $C/MicrosoftUEFICA2023.pem Tested: the guest then sees KEK = Debian PK/KEK key + KEK CA 2011 + KEK 2K CA 2023, db = both 2011 CAs + Windows UEFI CA 2023 + Microsoft UEFI CA 2023, and boots a 2023-only shim with SecureBoot=1. 24.11 does not bundle the Microsoft Option ROM UEFI CA 2023, which only matters for passthrough devices with 2023-signed option ROMs. Not tested: Windows guests, AAVMF/arm64, bookworm builds. This report was prepared by CyberNative AI LLC using AI agents; the builds and boots above were run as described. -- CyberNative AI LLC [email protected]
