Thanks @Stephen, noted and will be mindful next time.
This feature needs further definition and is not considered in scope for RHOSP 12/Pike. Laszlo are you able to provide context on what the bare minium OpenStack would need to setup/pass when calling Libvirt to create a guest is when enabling SecureBoot for a guest? There is some basic support for UEFI, but as I understand it we would also need to separately set the machine type for this to work + whatever other steps are required for SecureBoot?: https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/boot-from-uefi.html
Quoting <https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/boot-from-uefi.html>: > well tested and battle hardened Open Virtual Machine Firmware (OVMF) Haha, I don't recall whom I must have bribed to say this publicly about OVMF, but it's very flattering :) (Let's hope it won't come back and bite me...) > Update the libvirt guest XML configuration when the UEFI image property is > present Okay, so it seems the "nova compute libvirt driver" -- I hope I use the correct term -- generates a domain XML for the guest, similarly to virt-install, virt-manager, libguestfs. In that case, please consult with Rich Jones and Pavel Hrdina (CC'd), and refer to the following BZs / comments: - bug 1367615 comment 5 - bug 1367615 comment 7 - bug 1387479 comment 2 For simplicity's sake, here's a minimal domain XML fragment that showcases all the elements and attributes that are necessary for creating a new domain for use with the Secure Boot Feature and the SMM driver stack in OVMF: 01 <domain 02 type='kvm'> 03 <os> 04 <type 05 arch='x86_64' 06 machine='pc-q35-rhel7.3.0' 07 >hvm</type> 08 <loader 09 readonly='yes' 10 secure='yes' 11 type='pflash' 12 >/usr/share/OVMF/OVMF_CODE.secboot.fd</loader> 13 <nvram template='/usr/share/OVMF/OVMF_VARS.fd'/> 14 </os> 15 <features> 16 <smm state='on'/> 17 </features> 18 </domain> - Line 06: the machine type should be pc-q35-rhel7.3.0, or a later Q35 machine type. (Using qemu-kvm-rhev terms here. For upstream QEMU, the machine type should be pc-q35-2.4 or a later Q35 machine type.) - Line 10: The @secure attribute must be turned on, so that QEMU restricts pflash writes to code that executes in SMM. - Lines 09 and 11: these attribute settings are needed even for plain OVMF (without the secure boot feature and / or SMM). - Line 12: An OVMF binary must be identified that was built with -D SECURE_BOOT_ENABLE -D SMM_REQUIRE. Above I used the pathname that matches the "OVMF" binary package from Brew. - Line 13: This requires a bit more discussion. When creating a new domain, the <nvram> element can specify two things. First, with the @template attribute (as visible above), it explicitly identifies the variable store template for libvirt to instantiate the domain's private variable store from. (The pathname for the template file can be shared by several domains.) In this case, libvirt will automatically place the domain's varstore, with a unique name, under /var/lib/libvirt/qemu/nvram. Second, without the @template attribute, but with a pathname provided as the child text node of <nvram>, such as in <nvram>/full/path/to/varstore.fd</nvram>, the domain will use the referenced, preexistent file as varstore. (The pathname provided must be unique to the domain.) The variable store template "/usr/share/OVMF/OVMF_VARS.fd", as seen above, comes from the same "OVMF" package from Brew. It is a pristine, empty variable store template, with zero Secure Boot keys pre-enrolled, and with the Secure Boot Mode of Operation disabled. In order to enroll such keys and to enable the Secure Boot Mode of Operation, either the Setup TUI of OVMF has to be used (in the guest), or some UEFI application has to be run from the UEFI shell (also in the guest) that performs these actions. We provide one such example application on "/usr/share/OVMF/UefiShell.iso", also from the "OVMF" package, called "EnrollDefaultKeys.efi". It enrolls the "Microsoft Keys". Alternatively, this key enrollment can be done once interactively, during development, and (after shutting down the VM), the resultant variable store can be saved as a future variable store template. Using this (modified) varstore as a template for future domains, those new domains can be created with keys pre-enrolled and with the SB mode of operation pre-enabled. For this, either the @template attribute has to be pointed to this modified template, or else nova itself needs to create a separate copy of the modified template for each new domain, and place its pathname into <nvram>, as text contents. (For completeness, I'll mention that the <nvram> element can be omitted fully. In this case, libvirt will try to look up the <loader> pathname, from line 12, in the "nvram" stanza in "/etc/libvirt/qemu.conf", and pick the varstore template that is associated there with the firmware binary. This is the most convenient method for interactive users / direct libvirt users, but likely not the best for layered products.) - Line 16: enables SMM emulation in QEMU.
I don't really have much to add to Laszlo's excellent description, except to say that finding the right UEFI path (/usr/share/{AAVMF,OVMF,etc}) is a bit of a pain. It depends on the Linux distro, architecture and history. In libguestfs we carry around a "database" of paths which we test: https://github.com/libguestfs/libguestfs/blob/master/generator/uefi.ml#L31 So does virt-install: https://github.com/virt-manager/virt-manager/blob/master/virtinst/domcapabilities.py#L102 There's some movement to get this data included in libvirt so you can just write <loader firmware='uefi'/>. See: https://www.redhat.com/archives/libvir-list/2016-October/msg00045.html
(In reply to Richard W.M. Jones from comment #8) > I don't really have much to add to Laszlo's excellent description, > except to say that finding the right UEFI path (/usr/share/{AAVMF,OVMF,etc}) > is a bit of a pain. It depends on the Linux distro, architecture and > history. In libguestfs we carry around a "database" of paths which > we test: > > https://github.com/libguestfs/libguestfs/blob/master/generator/uefi.ml#L31 > > So does virt-install: > > https://github.com/virt-manager/virt-manager/blob/master/virtinst/ > domcapabilities.py#L102 Interestingly the original Nova patch hard-coded only two paths at this time: "x86_64": "/usr/share/OVMF/OVMF_CODE.fd", "aarch64": "/usr/share/AAVMF/AAVMF_CODE.fd" From: * https://review.openstack.org/#/c/262930/15/nova/virt/libvirt/driver.py * http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py#n126 Obviously as well as the path we have to get the machine type right, but we do have a facility for setting that from the image properties IIRC. > There's some movement to get this data included in libvirt so you > can just write <loader firmware='uefi'/>. See: > > https://www.redhat.com/archives/libvir-list/2016-October/msg00045.html This seems like a better approach going forward, do you know if there is a specific bug tracking this in RHBZ? I did come across the conversation referring to it in https://bugzilla.redhat.com/show_bug.cgi?id=1217444#c6 but it's not clear that directly tracks this workitem?
I believe bug 1217444 is the only bug related to that feature in RHEL, and it's not an exact match. So no.
Hmmm, what about bug 1295146? That's where Dan linked his own series at <https://www.redhat.com/archives/libvir-list/2016-October/msg00045.html> (see comment 8 above), in bug 1295146 comment 2.
(Although, bug 1295146 does indeed not target RHEL; it's an upstream libvirt BZ.)
I filed Bug # 1419191 because even though it *seems* like we have a lot of the configuration options and framework exposed in Nova for UEFI and OVMF we're not actually testing that - this is a pre-req for the SMM enablement requested here (validate what we have then build on it). Co-incidentally I just noticed Bug # 1401758 in my travels where not surprisingly Nova didn't cope well with a change in what was available in the newer OVMF package...
Also: WIP upstream Nova specification: https://review.openstack.org/#/c/506720/ -- Add UEFI Secure Boot support for QEMU/KVM guests, using OVMF And WIP: https://review.openstack.org/#/c/529611/ -- libvirt: Introduce SMM (System Management Mode) config class
For a long-term robust solution, based on mailing lists discussion there are two action items on QEMU and libvirt: (1) QEMU must define a firmware metadata format and file: https://bugzilla.redhat.com/show_bug.cgi?id=1546084 — RFE: Define and provide firmware (OVMF, etc) metadata format and file (2) And libvirt to take advantage of the above metadata files from QEMU and pick the relevant firmware files based on guest configuration https://bugzilla.redhat.com/show_bug.cgi?id=1295146 — RFE: provide a bios=uefi XML convenience option
Please note: There's a _ton_ of technical discussion in the following bug (which is closed a duplicate): https://bugzilla.redhat.com/show_bug.cgi?id=1419191
*** Bug 1419191 has been marked as a duplicate of this bug. ***
*** Bug 1563809 has been marked as a duplicate of this bug. ***
A small update: The upstream Nova spec is now merged: https://opendev.org/openstack/nova-specs/commit/f4c79e4f1a — Secure Boot support for KVM & QEMU guests has merged
Dropping tech preview metadata since this wasn't included in OSP17 planning and therefore will need to be reassessed for OSP16.1/OSP17.
I've started working on this, however, I run into some issues where secure boot is enabled even when I explicitly disable it. This has been reported via BZ 1929357. I'll work around this but depending on the outcome of that discussion, the firmware auto-configuration features introduced in libvirt 5.3 might prove less useful than originally anticipated.
This was included in the upstream Wallaby release.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Release of components for Red Hat OpenStack Platform 17.1 (Wallaby)), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2023:4577