uefi_secure_boot_in_libvirt

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

uefi_secure_boot_in_libvirt [2022/02/04 13:44] – 만듦 koovuefi_secure_boot_in_libvirt [2022/02/04 13:45] (현재) – koov
줄 5: 줄 5:
 Naturally, for nova’s libvirt virt driver to support UEFI, both libvirt and QEMU need to support it. This has been the case for many years, but recent versions of libvirt and QEMU have made working with UEFI significantly easier than previously. As noted in the [Secure Boot spec][0], libvirt 5.3 introduced support for the firmware auto-selection functionality provided by QEMU since QEMU 2.9. This QEMU feature relies on firmware JSON files that describe what each firmware file is for and how it can be described, as described in the QEMU spec. These files are typically provided by your distro and on a Fedora 33 host can be found at /usr/share/qemu/firmware. Here’s one such file, 40-edk2-ovmf-x64-sb-enrolled.json, taken from my host and provided by Fedora’s edk2-ovmf package: Naturally, for nova’s libvirt virt driver to support UEFI, both libvirt and QEMU need to support it. This has been the case for many years, but recent versions of libvirt and QEMU have made working with UEFI significantly easier than previously. As noted in the [Secure Boot spec][0], libvirt 5.3 introduced support for the firmware auto-selection functionality provided by QEMU since QEMU 2.9. This QEMU feature relies on firmware JSON files that describe what each firmware file is for and how it can be described, as described in the QEMU spec. These files are typically provided by your distro and on a Fedora 33 host can be found at /usr/share/qemu/firmware. Here’s one such file, 40-edk2-ovmf-x64-sb-enrolled.json, taken from my host and provided by Fedora’s edk2-ovmf package:
 <WRAP prewrap> <WRAP prewrap>
-<code bash>+<code vim>
 { {
     "description": "OVMF for x86_64, with SB+SMM, SB enabled, MS certs enrolled",     "description": "OVMF for x86_64, with SB+SMM, SB enabled, MS certs enrolled",
줄 54: 줄 54:
 This will yield: This will yield:
 <WRAP prewrap> <WRAP prewrap>
-<code bash>+<code xml>
 <os supported="yes"> <os supported="yes">
   <enum name="firmware">   <enum name="firmware">
줄 81: 줄 81:
 However, this isn’t all this can do. Libvirt can also negotiate the firmware for you when creating a new guest. Previously, to create a UEFI-based guest, one would need to specify something like the following: However, this isn’t all this can do. Libvirt can also negotiate the firmware for you when creating a new guest. Previously, to create a UEFI-based guest, one would need to specify something like the following:
 <WRAP prewrap> <WRAP prewrap>
-<code bash>+<code xml>
 <domain type="kvm"> <domain type="kvm">
   <!-- ... -->   <!-- ... -->
줄 99: 줄 99:
 This is no longer necessary, and libvirt will now do this for us. We can instead specify e.g.: This is no longer necessary, and libvirt will now do this for us. We can instead specify e.g.:
 <WRAP prewrap> <WRAP prewrap>
-<code bash>+<code xml>
 <domain type="kvm"> <domain type="kvm">
   <!-- ... -->   <!-- ... -->
줄 134: 줄 134:
 With the dependencies installed and the image downloaded, we can now create our guest or “domain”. Dump the following to e.g. /tmp/fedora-q35-uefi.xml: With the dependencies installed and the image downloaded, we can now create our guest or “domain”. Dump the following to e.g. /tmp/fedora-q35-uefi.xml:
 <WRAP prewrap> <WRAP prewrap>
-<code bash>+<code xml>
 <domain type="kvm"> <domain type="kvm">
   <name>fedora-q35-uefi-experiment</name>   <name>fedora-q35-uefi-experiment</name>
줄 216: 줄 216:
 The domain XML we’ll use for booting this image is virtually identical to the one used for Fedora previously. We could of course use the same specs as the Fedora 33-based guest and it would work just fine, but we’ve chosen to remove the VNC graphics device and display adapter, which are unnecessary for a distro like this, as well as reduce the RAM allocation. Dump the following XML to e.g. /tmp/alpine-q35-uefi.xml: The domain XML we’ll use for booting this image is virtually identical to the one used for Fedora previously. We could of course use the same specs as the Fedora 33-based guest and it would work just fine, but we’ve chosen to remove the VNC graphics device and display adapter, which are unnecessary for a distro like this, as well as reduce the RAM allocation. Dump the following XML to e.g. /tmp/alpine-q35-uefi.xml:
 <WRAP prewrap> <WRAP prewrap>
-<code bash>+<code xml>
 <domain type="kvm"> <domain type="kvm">
   <name>alpinelinux-q35-uefi-experiment</name>   <name>alpinelinux-q35-uefi-experiment</name>
줄 298: 줄 298:
  
 <WRAP prewrap> <WRAP prewrap>
-<code bash>+<code xml>
 <os> <os>
   <type arch='x86_64' machine='pc-q35-5.1'>hvm</type>   <type arch='x86_64' machine='pc-q35-5.1'>hvm</type>
줄 310: 줄 310:
 You’ll note that we requested secure='no' and libvirt has included this in the final XML, however, UEFI firmware with secure boot support, OVMF_CODE.secboot.fd, has been used, rather than OVMF_CODE.fd. In theory, this firmware should work for non-secure boot instances also but that’s not happening. The solution for now is to specify the path to the non-secure boot UEFI firmware when creating the instance, replacing the <os> element included in the XML above with the following: You’ll note that we requested secure='no' and libvirt has included this in the final XML, however, UEFI firmware with secure boot support, OVMF_CODE.secboot.fd, has been used, rather than OVMF_CODE.fd. In theory, this firmware should work for non-secure boot instances also but that’s not happening. The solution for now is to specify the path to the non-secure boot UEFI firmware when creating the instance, replacing the <os> element included in the XML above with the following:
 <WRAP prewrap> <WRAP prewrap>
-<code bash>+<code xml>
 <os> <os>
   <type arch='x86_64' machine='pc-q35-5.1'>hvm</type>   <type arch='x86_64' machine='pc-q35-5.1'>hvm</type>
  • uefi_secure_boot_in_libvirt.1643982269.txt.gz
  • 마지막으로 수정됨: 2022/02/04 13:44
  • 저자 koov