[Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file

[Kashyap Chamarthy <kchamart@redhat.com>]

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
    -- [libvirt] [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