Package: ovmf Version: 0~20181115.85588389-3 >From version 4.1 (due in August 2019) onwards, QEMU ships the so-called firmware "descriptor files". These are small JSON files that describe details about UEFI firmware binaries — such as the fimware binary path, its architecture, supported machine type, NVRAM template and so forth.
You can see examples of these files in the upstream QEMU Git: https://git.qemu.org/?p=qemu.git;a=tree;f=pc-bios/descriptors $> tree descriptors/ descriptors/ ├── 50-edk2-i386-secure.json ├── 50-edk2-x86_64-secure.json ├── 60-edk2-aarch64.json ├── 60-edk2-arm.json ├── 60-edk2-i386.json └── 60-edk2-x86_64.json QEMU 4.1 itself will ship the above files. However, Debian's `ovmf` package needs to ship modified versions of these JSON files that correspond to the OVMF biararies shipped in Debian. (See first reference further below for an example.) Why? Allow me to quote Laszlo Ersek, upstream EDK2/OVMF maintainer: Distributions providing their own EDK2 packages would not include the descriptors from upstream QEMU, even if they otherwise package QEMU. That's beause the descriptor files in QEMU match the firmware bundled with QEMU -- but the firmware images in the distros' own EDK2 packages are different. So, if a distro provides an EDK2 package, then the same EDK2 package should offer matching descriptors. QEMU offers descriptors (soon) because QEMU technically distributes edk2 firmware binaries (soon). [Where "soon" == QEMU 4.1] References: (1) Refer to this commit in Fedora's EDK2 package, which is equivalent to Debian's `ovmf` package, as an example: https://src.fedoraproject.org/rpms/edk2/c/674b3c8a27a8 (Ship the JSON firmware "descriptor files") (2) The Debian RFP to include a tool to generate OVMF "VARS" file with default UEFI keys enrolled: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927414 (RFP: qemu-ovmf-secureboot -- tool to enroll UEFI keys for Secure Boot) -- /kashyap
