libvirt: Handle alternative UEFI firmware binary paths
The OVMF binary paths differ based on the Linux distribution:
- Debian and Ubuntu:
- /usr/share/OVMF/OVMF_CODE.fd
- Fedora:
- /usr/share/edk2/ovmf/OVMF_CODE.fd (`symlink`s to /usr/share/OVMF/OVMF_CODE.fd)
- /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd (`symlink`s to /usr/share/OVMF/OVMF_CODE.secboot.fd)
- CentOS and RHEL:
- /usr/share/OVMF/OVMF_CODE.secboot.fd
- SUSE:
- /usr/share/qemu/ovmf-x86_64-opensuse-code.bin
Currently, Nova only checks for one location OVMF_CODE.fd. Let's also
check for the other two common distributions, SUSE and CentOS OVMF
binary paths. This is a short-term solution to fix two bugs.
In the long run:
- We will get rid of the "DEFAULT_UEFI_LOADER_PATH", which is used to
probe for firmware file paths. Instead, we'll use the more robust
approach of the recently introduced[1] get_domain_capabilities()[1]
to query for the firmware binary paths (as reported in the 'loader'
attribute).
- Use libvirt's (>=5.3) firmware auto-selection feature. Which is a
more robust way to decide UEFI boot (secure or otherwise). More
details of it in the spec here[2].
Reviewed: https:/ /review. opendev. org/348394 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=363710b6554 34a15b6b85d9ca6 5343210b104e56
Committed: https:/
Submitter: Zuul
Branch: master
commit 363710b655434a1 5b6b85d9ca65343 210b104e56
Author: Dirk Mueller <email address hidden>
Date: Thu Jul 28 16:39:19 2016 +0200
libvirt: Handle alternative UEFI firmware binary paths
The OVMF binary paths differ based on the Linux distribution:
- Debian and Ubuntu: OVMF/OVMF_ CODE.fd edk2/ovmf/ OVMF_CODE. fd
(`symlink` s to /usr/share/ OVMF/OVMF_ CODE.fd) edk2/ovmf/ OVMF_CODE. secboot. fd (`symlink`s to
/usr/ share/OVMF/ OVMF_CODE. secboot. fd) OVMF/OVMF_ CODE.secboot. fd qemu/ovmf- x86_64- opensuse- code.bin
- /usr/share/
- Fedora:
- /usr/share/
- /usr/share/
- CentOS and RHEL:
- /usr/share/
- SUSE:
- /usr/share/
Currently, Nova only checks for one location OVMF_CODE.fd. Let's also
check for the other two common distributions, SUSE and CentOS OVMF
binary paths. This is a short-term solution to fix two bugs.
In the long run:
- We will get rid of the "DEFAULT_ UEFI_LOADER_ PATH", which is used to capabilities( )[1]
probe for firmware file paths. Instead, we'll use the more robust
approach of the recently introduced[1] get_domain_
to query for the firmware binary paths (as reported in the 'loader'
attribute).
- Use libvirt's (>=5.3) firmware auto-selection feature. Which is a
more robust way to decide UEFI boot (secure or otherwise). More
details of it in the spec here[2].
[1] https:/ /opendev. org/openstack/ nova/commit/ 297f3ba687 -- Add
infrastructure for invoking libvirt's getDomainCapabi lities API specs.openstack .org/openstack/ nova-specs/ specs/train/ approved/ allow-secure- boot-for- qemu-kvm- guests. html
[2] http://
Co-Authored-By: Kashyap Chamarthy <email address hidden> boot-for- qemu-kvm- guests 39981606d5234fd 837ea738e1d
Closes-Bug: 1607400
Closes-Bug: 1825386
blueprint: allow-secure-
Signed-off-by: Kashyap Chamarthy <email address hidden>
Change-Id: I28afdb09d300be