[Bug 2004618] Re: focal change to 4M images changes virtinst default flavor

[Mate Kukri]

** Changed in: edk2 (Ubuntu)
       Status: Confirmed => Incomplete

** Changed in: edk2 (Ubuntu Focal)
       Status: Confirmed => Incomplete

** Changed in: edk2 (Ubuntu Focal)
       Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to edk2 in Ubuntu.
https://bugs.launchpad.net/bugs/2004618

Title:
  focal change to 4M images changes virtinst default flavor

Status in edk2 package in Ubuntu:
  Incomplete
Status in virt-manager package in Ubuntu:
  Invalid
Status in edk2 source package in Focal:
  Won't Fix
Status in virt-manager source package in Focal:
  Fix Released

Bug description:
  [ Impact ]

    * The fix for bug 1885662 has caused a regression in virt-install,
  where the default "--boot uefi" firmware image has changed from
  "OVMF_CODE.fd" (no secure boot) to "OVMF_CODE_4M.ms.fd" (secure boot,
  enrolled)

    * This is related to how virt-install selects a firmware from the
  offered firmwares. virt-install uses a hard-coded UEFI firmware
  pattern list to match against the offered patterns. The pattern list
  can be found in virtinst/domcapabilities.py (search for
  _uefi_arch_patterns). The current x86_64 pattern list is as follows:

     _uefi_arch_patterns = {
        /*...*/
        "x86_64": [
            r".*edk2-x86_64-.*\.fd",  # upstream qemu
            r".*OVMF_CODE\.fd",  # RHEL
            r".*ovmf-x64/OVMF.*\.fd",  # gerd's firmware repo
            r".*ovmf-x86_64-.*",  # SUSE
            r".*ovmf.*", ".*OVMF.*",  # generic attempt at a catchall
        ],
        /*...*/
      }

    * virt-install uses `find_uefi_path_for_arch` function to select a
  UEFI FW path from the firmware descriptor list. The OVMF firmware
  descriptor list before the update that caused the regression was
  looking like this:

      40-edk2-x86_64-secure-enrolled.json - OVMF_CODE.ms.fd
      50-edk2-x86_64-secure.json          - OVMF_CODE.secboot.fd
      60-edk2-x86_64.json                 - OVMF_CODE.fd

    * Looking at the implementation of `find_uefi_path_for_arch`, it
  iterates over the UEFI arch pattern list to match against the offered
  firmwares:

      domcapabilities.py/find_uefi_path_for_arch:
      /* ... */
      for pattern in patterns:
              for path in firmware_files:
                  if re.match(pattern, path):
                      return path
      /* ... */

     The first pattern r".*edk2-x86_64-.*\.fd" matches to none, the
  second pattern r".*OVMF_CODE\.fd", matches to the OVMF_CODE.fd,
  OVMF_CODE.fd is selected.

    * The fix for LP#1885662 has changed the offered firmware names as
  follows:

      40-edk2-x86_64-secure-enrolled.json - OVMF_CODE_4M.ms.fd
      50-edk2-x86_64-secure.json          - OVMF_CODE_4M.secboot.fd
      60-edk2-x86_64.json                 - OVMF_CODE_4M.fd

      The pattern r".*OVMF_CODE\.fd" no longer matches to anything, and
  the loop proceeds to the next pattern until a match is found. The last
  pattern ".*OVMF.*" matches, but it matches to first offered firmware
  now instead of the last one, and returns OVMF_CODE_4M.ms.fd as UEFI
  firmware path. The returned OVMF_CODE_4M.ms.fd is a secure boot
  capable/key enrolled firmware file, where the old one was non-secure
  boot firmware; hence the regression.

    * This SRU fixes the issue by updating the r".*OVMF_CODE\.fd"
  pattern as r".*OVMF_CODE(_4M)?\.fd" to reflect the changes made to
  OVMF and restore the old behavior back.

    * Note that this regression affects only the new VMs, not the
  existing VMS.

  [ Test Plan ]

   * To see the old behavior:

     - lxc launch ubuntu:focal test-ovmf-r # or equivalent vm/container choice
     - lxc shell test-ovmf-r
     - apt install ovmf=0~20191122.bd85bf54-2ubuntu3.3 virtinst # OVMF version before the regression
     - apt install qemu-kvm libvirt-daemon-system
     - systemctl restart libvirtd # ensure fw descriptors are reloaded
     - virt-install --boot uefi --print-xml --memory 1 --disk none --machine q35 | grep "/usr/share/OVMF"
     - # should output: <loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE.fd</loader>
     - # selected default firmware is non-secure boot kind

   * To see the new behavior (regression):
     - lxc launch ubuntu:focal test-ovmf-r # or equivalent vm/container choice
     - lxc shell test-ovmf-r
     - apt install ovmf=0~20191122.bd85bf54-2ubuntu3.4 virtinst
     - apt install qemu-kvm libvirt-daemon-system
     - systemctl restart libvirtd # ensure fw descriptors are reloaded
     - virt-install --boot uefi --print-xml --memory 1 --disk none --machine q35 | grep "/usr/share/OVMF"
     - # should output: <loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE_4M.ms.fd</loader>
     - # selected default firmware is different kind (secure boot capable/key enrolled) than the previous
     - # version

   * Test the fix:
     - Execute steps under "To see the new behavior (regression)"
     - # Enable the PPA that contains the virt-install with the fix
     - # and upgrade the virt-install package:
     - sudo add-apt-repository ppa:mustafakemalgilor/lp-2004618
     - sudo apt update
     - sudo apt upgrade
     - # Check "virt-install" output again:
     - virt-install --boot uefi --print-xml --memory 1 --disk none --machine q35 | grep "/usr/share/OVMF"
     - # should output: <loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE_4M.fd</loader>
     - # selected default firmware is non-secure boot kind

  [ Where problems could occur ]

    * The change is localized and it compliments the changes made to the
  OVMF package, therefore the risk of regression is considered low.

    * This patch can only affect virt-install's behavior if other
  packages offer OVMF firmware files with the new "_4M" suffix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2004618/+subscriptions