[ 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.
For reference, I'm attaching the logs I was looking at yesterday that pointed me to the virtinst issue. I collected it by turning on the following debug settings in libvirtd.conf:
log_filters=
log_outputs=
And ran libvirtd in the foreground to collect it.
You'll see that the probing pattern between old ovmf and new ovmf changed. After applying a patch to virtinst that also matches the 4M variants, the probing pattern when using the new ovmf now matches the old one.