Problem background
------------------
The various OVMF binary file names and paths are slightly different[+]
for each Linux distribution. And each high-level management tool
(libguestfs, oVirt, `virt-manager` and OpenStack Nova) is inventing its
own approach to detect and configure the said OVMF files. This email
thread is about arriving at some common understanding to make this a bit
more "unified" by addressing these needs in QEMU and libvirt.
Suggested approach
------------------
Based on an upstream discussion on 'virt-tools'[1] mailing list and some
Bugzillas, Gerd Hoffmann, Laszlo Ersek and Dan Berrangé had a suggestion
to define a firmware metadata format and file (example in [1]):
- For each firmware file we need a metadata file in a well defined
location, e.g. /usr/share/qemu/bios/ that lists stuff like:
- Path to the firmware binary
- Path to the pre-built OVMF 'vars' file (if any)
- Support architectures - associated QEMU feature flags (Secure
Boot)
- If the binary provides / requires SMM (System Management Mode)
Essentially, QEMU would define[*] the file format, and provide
metadata files from any ROMs it ships directly. If Linux
distributions / vendors ship extra ROMs like OVMF, etc then they
should provide suitable metadata files.
- Libvirt can read these metadata files and then pick the correct
firmware binary based on the settings for the guest.
- Management tools can then wire up the libvirt-based OVMF SB (Secure
Boot) configuration.
[*] Open question: Who, between QEMU and libvirt, should define the said
firmware metadata format and file?
References
----------
[1] A past proposal from Gerd to create a sort of a "firmware registry"
https://www.redhat.com/archives/virt-tools-list/2014-September/msg00145.html
[2] A libvirt upstream RFE bug requesting to simplify handling UEFI
https://bugzilla.redhat.com/show_bug.cgi?id=1295146 -- RFE: provide
a bios=uefi XML convenience option
[3] DanPB wrote a PoC in libvirt:
https://www.redhat.com/archives/libvir-list/2016-October/msg00045.html
-- [PATCH 0/3] Make UEFI firmware config simpler
But later came to the conclusion that it is flawed, and said we go
the route of "Suggested approach" mentioned earlier).
[*] OVMF package path names for different distributions
-------------------------------------------------------
- Debian (https://packages.debian.org/stretch/all/ovmf/filelist)
- /usr/share/OVMF/OVMF_CODE.fd
- /usr/share/OVMF/OVMF_VARS.fd
- OpenSUSE (package: "qemu-ovmf-x86_64" -- and it has *35*
files in that package):
- /usr/share/qemu/ovmf-x86_64-opensuse-code.bin
- /usr/share/qemu/ovmf-x86_64-opensuse-vars.bin [...]
Their RPM spec file gives some hints (where all the files with
'ms' means signed with MS keys; the files with 'opensuse-4096'
means signed with OpenSUSE 4096 bit CA keys -- I think that's one
of the points of Secure Boot, to let people have control over
system keys):
https://build.opensuse.org/package/view_file/openSUSE:Factory/ovmf/ovmf.spec?expand=1
- Fedora 27 (package: "edk2-ovmf", x86_64):
- /usr/share/edk2/ovmf/OVMF_CODE.fd
- /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd
- /usr/share/edk2/ovmf/OVMF_VARS.fd
- RHEL-7.4 (package: "OVMF", x86_64):
- /usr/share/OVMF/OVMF_CODE.secboot.fd
- /usr/share/OVMF/OVMF_VARS.fd
- Gerd's firmware repo from Git:
- /usr/share/edk2.git/ovmf-x64/OVMF_VARS-need-smm.fd
- /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
--
/kashyap
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
