__________________________________________________

            ADDRESS REST OF THE FEEDBACK ON THE SECURE BOOT
                               SPEC OVMF
           __________________________________________________


Table of Contents
_________________

1 Review: [https://review.openstack.org/#/c/506720/]
2 Notes based on John Garbutt's review [0/7]


1 Review: [https://review.openstack.org/#/c/506720/]
====================================================


2 Notes based on John Garbutt's review [0/8]
============================================

  - [ ] Overall, turn the spec a bit "upside down" to reorganize some
        content.
  - [ ] Adjust the "Use Cases" section to focus just on the
        guest-level protection.  Then reference the other white paper
        for more details.
  - [ ] Spell out that Secure Boot in this spec is only concerned with
        *guest*-level protection; and "what if you don't trust the host"
        is a completely different problem space, and is out of scope
        here.
  - [ ] Update the Proposed Change section to reflect changes to Nova:
        (1) copy Hyper-V interface; (2) libvirt does all the
        heavy-lifting, i.e. show what the XML is, then describe what it
        does; (3) scheduling to make sure we land the instance on a
        SecureBoot-capable host
  - [ ] Write some detail about how we're going to ask libvirt if it can
        do Secure Boot. Introduce: _has_uefi_secure_boot_support() bit to
        check if libvirt can support Secure Boot, by querying for the
        presence of 'efi' firmware, via the getDomainCapabilities() API
  - [ ] Bring the last two Work Items (that talk about the metadata
        property) to the forefront
  - [ ] Remove background detail on what was considered before, from the
        Work Items section
  - [ ] Spell out in the spec that we only support using the default
        UEFI keys in the first implementation.  I.e. allowing usage of
        'os_secure_boot_signature' is a "nice to have".
  - [ ] In the first version, note that we will simply error-out if
        there's no support for Secure Boot.  But note in the future, we
        can add a "request spec filter" that is similar to the existing
        image type filter.