Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1369007 - RFE: UEFI Secure Boot support for Nova instances (using SMM & OVMF)
Summary: RFE: UEFI Secure Boot support for Nova instances (using SMM & OVMF)
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova
Version: unspecified
Hardware: Unspecified
OS: Linux
high
medium
Target Milestone: ---
: ---
Assignee: Kashyap Chamarthy
QA Contact: Joe H. Rahme
URL:
Whiteboard:
: 1419191 (view as bug list)
Depends On: 1564270 1564280 1600230 1561128 1605127
Blocks: 1442136 1445659 1474725 1419191
TreeView+ depends on / blocked
 
Reported: 2016-08-22 10:30 UTC by Luke Hinds
Modified: 2019-04-12 14:17 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
OpenStack gerrit 506720 None None None 2018-01-19 21:02:32 UTC

Comment 3 Luke Hinds 2016-09-02 16:22:16 UTC
Thanks @Stephen, noted and will be mindful next time.

Comment 5 Stephen Gordon 2017-01-26 19:26:03 UTC
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

Comment 6 Stephen Gordon 2017-01-26 19:26:04 UTC
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

Comment 7 Laszlo Ersek 2017-01-27 04:11:39 UTC
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.

Comment 8 Richard W.M. Jones 2017-01-27 08:54:32 UTC
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

Comment 9 Stephen Gordon 2017-02-03 18:13:36 UTC
(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?

Comment 10 Richard W.M. Jones 2017-02-03 19:38:38 UTC
I believe bug 1217444 is the only bug related to that feature in RHEL,
and it's not an exact match.  So no.

Comment 11 Laszlo Ersek 2017-02-03 19:41:51 UTC
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.

Comment 12 Laszlo Ersek 2017-02-03 19:43:17 UTC
(Although, bug 1295146 does indeed not target RHEL; it's an upstream libvirt BZ.)

Comment 13 Stephen Gordon 2017-02-03 20:48:01 UTC
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...

Comment 14 Kashyap Chamarthy 2018-01-17 10:50:21 UTC
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

Comment 15 Kashyap Chamarthy 2018-02-21 16:11:35 UTC
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

Comment 16 Kashyap Chamarthy 2018-02-25 16:57:03 UTC
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

Comment 17 Lee Yarwood 2018-03-27 12:21:31 UTC
*** Bug 1419191 has been marked as a duplicate of this bug. ***

Comment 20 Kashyap Chamarthy 2018-08-31 15:00:14 UTC
*** Bug 1563809 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.