| 2023-02-03 05:35:38 |
dann frazier |
bug |
|
|
added bug |
| 2023-02-03 05:38:05 |
dann frazier |
bug task added |
|
virt-manager (Ubuntu) |
|
| 2023-02-03 14:34:43 |
dann frazier |
nominated for series |
|
Ubuntu Focal |
|
| 2023-02-03 14:34:43 |
dann frazier |
bug task added |
|
virt-manager (Ubuntu Focal) |
|
| 2023-02-03 14:34:43 |
dann frazier |
bug task added |
|
edk2 (Ubuntu Focal) |
|
| 2023-02-03 14:56:33 |
dann frazier |
attachment added |
|
libvirt-debug-old-ovmf.patch https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2004618/+attachment/5644633/+files/libvirt-debug-old-ovmf.patch |
|
| 2023-02-03 14:59:15 |
dann frazier |
attachment added |
|
libvirt-debug-new-ovmf.log https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2004618/+attachment/5644634/+files/libvirt-debug-new-ovmf.log |
|
| 2023-02-03 14:59:47 |
dann frazier |
attachment added |
|
virtinst-ovmf-4M-compat.patch https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2004618/+attachment/5644635/+files/virtinst-ovmf-4M-compat.patch |
|
| 2023-02-03 15:00:07 |
dann frazier |
attachment added |
|
libvirt-debug-old-ovmf+patched-virtinst.log https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2004618/+attachment/5644636/+files/libvirt-debug-old-ovmf+patched-virtinst.log |
|
| 2023-02-03 15:00:36 |
dann frazier |
attachment added |
|
libvirt-debug-new-ovmf+patched-virtinst.log https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2004618/+attachment/5644637/+files/libvirt-debug-new-ovmf+patched-virtinst.log |
|
| 2023-02-03 16:22:33 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2023-02-14 18:45:14 |
dann frazier |
bug |
|
|
added subscriber Ubuntu Server |
| 2023-02-16 06:16:31 |
Mustafa Kemal Gilor |
bug |
|
|
added subscriber Mustafa Kemal Gilor |
| 2023-02-23 12:53:41 |
Launchpad Janitor |
edk2 (Ubuntu): status |
New |
Confirmed |
|
| 2023-02-23 12:53:41 |
Launchpad Janitor |
virt-manager (Ubuntu): status |
New |
Confirmed |
|
| 2023-02-23 12:53:41 |
Launchpad Janitor |
edk2 (Ubuntu Focal): status |
New |
Confirmed |
|
| 2023-02-23 12:53:41 |
Launchpad Janitor |
virt-manager (Ubuntu Focal): status |
New |
Confirmed |
|
| 2023-02-24 11:17:00 |
Mustafa Kemal Gilor |
edk2 (Ubuntu Focal): assignee |
|
Mustafa Kemal Gilor (mustafakemalgilor) |
|
| 2023-03-07 11:39:34 |
Mustafa Kemal Gilor |
description |
The fix for bug 1885662 changed the QEMU descriptors that ovmf provides to advertise the new 4M images instead of the old 2M images. That had an unintended side-effect with virtinst. Where previously '--boot uefi' would cause the VM to use OVMF_CODE.fd (the non-secure-boot, no-keys-enrolled variant), after the upgrade VMs are getting OVMF_CODE_4M.ms.fd (the secure-boot/MS-keys-enrolled variant).
Note: Users can override this by explicitly naming the loader file they want to use using:
"--boot loader=<path>,loader_ro=yes,loader_type=pflash"
As best I can tell, this is happening because focal's virt-install has a hardcoded list of loader filename patterns it prefers if the user didn't explicitly specify one. From domcapbilities.py:
_uefi_arch_patterns = {
"i686": [
r".*ovmf-ia32.*", # fedora, gerd's firmware repo
],
"x86_64": [
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
],
Before the upgrade, libvirt would advertise the OVMF_CODE.fd file found in the descriptor. That matches the ".*OVMF_CODE\.fd" regex. So while libvirt processed the descriptors in normal order, and while any of them should meet the feature requirements, it held out for one with a file name that matched the regex:
40-edk2-x86_64-secure-enrolled.json - OVMF_CODE.ms.fd - NO MATCH
50-edk2-x86_64-secure.json - OVMF_CODE.secboot.fd - NO MATCH
60-edk2-x86_64.json - OVMF_CODE.fd - MATCH!
After the upgrade, the advertised file paths changed to begin with OVMF_CODE_4M. So now none of them match virtinst's built-in pattern. Because of that, the negotiation seems to select an option based on capabilities alone. And what do you know? The first one works, so it stops there:
40-edk2-x86_64-secure-enrolled.json - OVMF_CODE_4M.ms.fd - MATCH!
50-edk2-x86_64-secure.json - OVMF_CODE_4M.secboot.fd - (no need to check)
60-edk2-x86_64.json - OVMF_CODE.fd - (no need to check)
Note that this is not a problem with jammy. I saw in the virtinst changelog that it has changed the interface it uses to request a UEFI firmware from libvirt, so perhaps that is why. We should confirm.
For focal, perhaps we need to restore the previous behavior by modifying the regex to also match the _4M variants. |
[ Impact ]
* The fix for LP#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
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ 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. |
|
| 2023-03-07 11:43:36 |
Mustafa Kemal Gilor |
description |
[ Impact ]
* The fix for LP#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
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ 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. |
[ Impact ]
* The fix for LP#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. |
|
| 2023-03-07 11:44:09 |
Mustafa Kemal Gilor |
virt-manager (Ubuntu Focal): assignee |
|
Mustafa Kemal Gilor (mustafakemalgilor) |
|
| 2023-03-07 11:44:13 |
Mustafa Kemal Gilor |
edk2 (Ubuntu Focal): assignee |
Mustafa Kemal Gilor (mustafakemalgilor) |
|
|
| 2023-03-07 12:05:55 |
Mustafa Kemal Gilor |
merge proposal linked |
|
https://code.launchpad.net/~mustafakemalgilor/ubuntu/+source/virt-manager/+git/virt-manager/+merge/438451 |
|
| 2023-06-16 03:49:55 |
Ubuntu Archive Robot |
bug |
|
|
added subscriber Christian Ehrhardt |
| 2023-06-21 18:47:33 |
Robie Basak |
tags |
patch |
patch regression-update |
|
| 2023-06-28 10:33:34 |
Robie Basak |
description |
[ Impact ]
* The fix for LP#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. |
[ 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. |
|
| 2023-06-28 10:42:10 |
Robie Basak |
virt-manager (Ubuntu Focal): status |
Confirmed |
Fix Committed |
|
| 2023-06-28 10:42:11 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-06-28 10:42:12 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2023-06-28 10:42:14 |
Robie Basak |
tags |
patch regression-update |
patch regression-update verification-needed verification-needed-focal |
|
| 2023-07-06 19:55:25 |
Joao Andre Simioni |
tags |
patch regression-update verification-needed verification-needed-focal |
patch regression-update verification-done-focal verification-needed |
|
| 2023-07-06 19:58:21 |
Joao Andre Simioni |
bug |
|
|
added subscriber Joao Andre Simioni |
| 2023-07-12 10:14:54 |
Robie Basak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2023-07-12 10:14:53 |
Launchpad Janitor |
virt-manager (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2023-07-12 10:15:02 |
Robie Basak |
virt-manager (Ubuntu): status |
Confirmed |
Invalid |
|
