#1106535 ovmf: Potential regression: ovmf package update from Debian bookworm to trixie breaks AMD-SEV

Package:
ovmf
Source:
ovmf
Submitter:
Stephane Poignant
Date:
2026-07-07 16:35:01 UTC
Severity:
normal
#1106535#5
Date:
2025-05-25 16:43:24 UTC
From:
To:
After upgrading from bookworm to trixie (ovmf package upgraded from 2022.11-6+deb12u2 to 2025.02-6), my SEV encrypted VMs became unable to boot.
The OVMF bootloader hang, with the kvm process at 100% CPU, and nothing printed in the console. Nothing changes until the VM is destroyed manually.

Other VMs are not affected. If i disable SEV by just removing the launchSecurity section from the VM config, it boots successfully.

After more testing i could narrow down the root cause to the ovmf package, and more precisely determine that the regression was introduced between 2024.02-2 (last working version) and 2024.05-1 (first broken one).

Reproducing steps:

- Start with a bookworm or trixie system
Initially, version [2024.02-2](https://snapshot.debian.org/archive/debian/20240604T203040Z/pool/main/e/edk2/ovmf_2024.02-2_all.deb) of the `ovmf` package is installed on the system.
```
# dpkg -i ovmf_2024.02-2_all.deb
```

- Create a SEV encrypted VM, the following is a minimalistic reproducing config, inspired from [this example](https://github.com/AMDESE/AMDSEV/blob/master/xmls/sample-sev.xml):
```
# cat v-testsev.xml
<domain type='kvm'>
  <name>v-testsev</name>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <memoryBacking>
    <locked/>
  </memoryBacking>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc-q35-9.2'>hvm</type>
    <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE_4M.ms.fd</loader>
    <nvram template='/usr/share/OVMF/OVMF_VARS_4M.ms.fd'>/var/lib/libvirt/qemu/nvram/v-testsev_VARS.fd</nvram>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
  </features>
  <cpu mode='host-passthrough' check='none' migratable='on'>
    <cache mode='passthrough'/>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <controller type='usb' index='0' model='none'/>
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
    </channel>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <audio id='1' type='none'/>
    <memballoon model='virtio'/>
    <rng model='virtio'>
      <backend model='random'>/dev/urandom</backend>
    </rng>
  </devices>
  <launchSecurity type='sev'>
    <policy>0x0003</policy>
    <cbitpos>47</cbitpos>
    <reducedPhysBits>1</reducedPhysBits>
  </launchSecurity>
</domain>

# virsh define v-testsev.xml
```

- Start the VM:
```
# virsh start --console v-testsev
Domain 'v-testsev' started
Connected to domain 'v-testsev'
Escape character is ^] (Ctrl + ])
BdsDxe: No bootable option or device was found.
BdsDxe: Press any key to enter the Boot Manager Menu.
...

 Standard PC (Q35 + ICH9, 2009)
 pc-q35-9.2                                          2.00 GHz
 2024.02-2                                           2048 MB RAM
...
```

The loader starts and successfully boots into the setup utility as expected.

- Destroy the VM is destroyed, delete the nvram varfile upgrade ovmf to [2024.05-1](https://snapshot.debian.org/archive/debian/20240604T203040Z/pool/main/e/edk2/ovmf_2024.05-1_all.deb):
```
# rm /var/lib/libvirt/qemu/nvram/v-testsev_VARS.fd
# dpkg -i ovmf_2024.05-1_all.deb
```

- Try starting the VM again:
```
# virsh start --console v-testsev
Domain 'v-testsev' started
Connected to domain 'v-testsev'
Escape character is ^] (Ctrl + ])
<hangs>

# top
...
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  21343 libvirt+  20   0 2497576   2.1g  60444 S 100.3   1.7   0:28.85 kvm
...

# strace -p 21343,21351,21354,21355
strace: Process 21343 attached
strace: Process 21351 attached
strace: Process 21354 attached
strace: Process 21355 attached
[pid 21355] ioctl(18, KVM_RUN <unfinished ...>
[pid 21354] ppoll([{fd=15, events=POLLIN}, {fd=16, events=POLLIN}, {fd=17, events=POLLIN}], 3, NULL, NULL, 8 <unfinished ...>
[pid 21351] futex(0x5557bd5c84a8, FUTEX_WAIT, 4294967295, NULL <unfinished ...>
[pid 21343] ppoll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=78, events=POLLIN}], 5, {tv_sec=27702, tv_nsec=581671146}, NULL, 8
```

The VM remains unresponsive, nothing on the console, kvm process at 100% CPU. The issue is reproduced.

- Destroy the VM, remove the launchSecurity from the config, and restart it:
```
~# virsh destroy v-testsev
Domain 'v-testsev' destroyed

# virsh edit v-testsev
<remove launchSecurity section>

# virsh start --console v-testsev
Domain 'v-testsev' started
Connected to domain 'v-testsev'
Escape character is ^] (Ctrl + ])
BdsDxe: No bootable option or device was found.
BdsDxe: Press any key to enter the Boot Manager Menu.
...
 Standard PC (Q35 + ICH9, 2009)
 pc-q35-9.2                                          2.00 GHz
 2025.02-6                                           2048 MB RAM
...
```

The loader starts successfully and boot into the menu. This shows that the issue only happens when SEV is configured.

#1106535#10
Date:
2025-07-19 00:47:22 UTC
From:
To:
Hi Stephane,

I don't have access to a system that supports SEV. But it's possible that this is a symptom of the EFI_MEMORY_ATTRIBUTE protocol that was enabled in 2025.02-6, but later disabled in 2025.02-8. Would you mind testing it and reporting back?

  -dann

#1106535#15
Date:
2025-07-20 21:57:31 UTC
From:
To:
Hi Dann,

Thanks for the suggestion. So on my system with the latest 2025.02-8, i've tried both OVMF_CODE_4M.secboot.fd and OVMF_CODE_4M.secboot.strictnx.fd images. Between each attempt, i've deleted the virtual machine's nvram vars file to have those regenerated from the template.

In either cases, i unfortunately still observed the same exact behaviour (the VM using SEV does not boot with no message printed on the console and kvm process stuck at 100% CPU).

Then, after putting back OVMF_CODE_4M.secboot.fd from 2024.02-2, it would start normally again.

So it does not appear to be related with EFI_MEMORY_ATTRIBUTE (strictnx).

Thanks for the help,
Best regards,
--- Stephane POIGNANT +33 682 960 589
#1106535#20
Date:
2026-07-07 16:31:52 UTC
From:
To:
I also experienced this bug (unresponsive guest, blank console, pegged
CPU) when booting SEV guests on Ubuntu 26.04 with ovmf images that
enable both nvram and secure boot:

OVMF_CODE_4M.ms.fd
 - symlinked to OVMF_CODE_4M.secboot.fd
 - similar image in Fedora is OVMF_CODE.secboot.fd which is also affected

However, the following ovmf images work fine:

OVMF_CODE_4M.fd
 - nvram yes
 - secure boot no
 - similar image in Fedora is OVMF_CODE.fd which also works fine

OVMF.amdsev.fd
 - stateless
 - secure boot no
 - supports SEV launch secret
 - packaged in Debian unstable (ovmf-amdsev), Ubuntu 26.04
(ovmf-amdsev), Fedora 44 (edk2-ovmf)

OVMF.stateless.fd
 - stateless
 - secure boot supported but disabled
 - packaged in Fedora 44 (edk2-ovmf)

OVMF.stateless.secboot.fd
 - stateless
 - secure boot enabled with Microsoft and Red Hat keys
 - packaged in Fedora 44 (edk2-ovmf)

So for now I would suggest either using OVMF.amdsev.fd from sid or
OVMF.stateless.secboot.fd from Fedora (and in the future adding the
stateless secure boot build config to Debian).

For OVMF.amdsev.fd, you can use it with direct kernel boot and passing
LUKS key as a launch secret, e.g., for legacy SEV after verifying SEV
certificate and generating session keys with sevctl and launch
measurement with virt-qemu-sev-validate. For
OVMF.stateless.secboot.fd, you can modify it to hard-code the secure
boot keys with virt-fw-vars from python3-virt-firmware package.