The main motivation behind this series was making it as simple as
possible ("one click") to enable Secure Boot for a VM.

In the process I ended up fixing, improving and cleaning up various
parts of the firmware selection interface.

GitLab branch: https://gitlab.com/abologna/libvirt/-/commits/firmware
Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/571485540

Andrea Bolognani (28):
  tests: Remove firmware bits from unrelated tests
  tests: Use firmware autoselection on aarch64
  tests: Drop bios-nvram-os-interleave test
  tests: Rename and reorganize firmware tests
  tests: Use minimal hardware for firmware tests
  tests: Don't set NVRAM path manually
  tests: Don't use loader.secure=no with firmware autoselection
  tests: Add more firmware tests
  conf: Move virDomainLoaderDefParseXML()
  conf: Rename virDomainLoaderDefParseXMLNvram()
  conf: Move setting type for NVRAM source
  conf: Move nvramTemplate parsing
  conf: Handle NVRAM in virDomainLoaderDefParseXML()
  conf: Rename virDomainLoaderDefParseXML() argument
  conf: Use nodes in virDomainLoaderDefParseXMLNvram()
  conf: Always parse NVRAM path if present
  conf: Enable secure-boot when enrolled-keys is enabled
  conf: Add return value to virDomainDefPostParseOs()
  conf: Reject enrolled-keys=yes with secure-boot=no
  conf: Always parse all firmware information
  conf: Refactor virDomainDefOSValidate()
  conf: Validate firmware configuration more thoroughly
  conf: Always parse firmware features
  conf: Reject features when using manual firmware selection
  qemu_firmware: Enable loader.secure when requires-smm
  qemu_firmware: enrolled-keys requires secure-boot
  docs: Add kbase page for Secure Boot
  NEWS: Document improvements to firmware autoselection

 NEWS.rst                                      |   5 +
 docs/kbase/index.rst                          |   3 +
 docs/kbase/meson.build                        |   1 +
 docs/kbase/secureboot.rst                     | 102 ++++++++++
 src/conf/domain_conf.c                        | 182 ++++++++++--------
 src/conf/domain_validate.c                    |  83 ++++++--
 src/qemu/qemu_firmware.c                      |  16 +-
 tests/qemusecuritytest.c                      |   6 +-
 .../aarch64-os-firmware-efi.xml               |  31 ---
 .../bios-nvram-os-interleave.xml              |  40 ----
 .../bios-nvram-rw-implicit.xml                |  35 ----
 tests/qemuxml2argvdata/bios-nvram-rw.xml      |  35 ----
 tests/qemuxml2argvdata/bios-nvram-secure.xml  |  35 ----
 tests/qemuxml2argvdata/bios.xml               |  37 ----
 ...firmware-auto-bios-nvram.x86_64-latest.err |   1 +
 .../firmware-auto-bios-nvram.xml              |  18 ++
 ... => firmware-auto-bios.x86_64-latest.args} |  12 +-
 tests/qemuxml2argvdata/firmware-auto-bios.xml |  17 ++
 ...ware-auto-efi-aarch64.aarch64-latest.args} |   6 +-
 ...uefi.xml => firmware-auto-efi-aarch64.xml} |  12 +-
 ...enrolled-keys-no-secboot.x86_64-latest.err |   1 +
 ...ware-auto-efi-enrolled-keys-no-secboot.xml |  21 ++
 ...auto-efi-enrolled-keys.x86_64-latest.args} |  14 +-
 .../firmware-auto-efi-enrolled-keys.xml       |  20 ++
 ...auto-efi-loader-insecure.x86_64-latest.err |   1 +
 .../firmware-auto-efi-loader-insecure.xml     |  18 ++
 ...are-auto-efi-loader-path.x86_64-latest.err |   1 +
 .../firmware-auto-efi-loader-path.xml         |  18 ++
 ...auto-efi-loader-secure.x86_64-latest.args} |  15 +-
 .../firmware-auto-efi-loader-secure.xml       |  18 ++
 ...o-efi-no-enrolled-keys.x86_64-latest.args} |   3 -
 .../firmware-auto-efi-no-enrolled-keys.xml    |  20 ++
 ...re-auto-efi-no-secboot.x86_64-latest.args} |   3 -
 .../firmware-auto-efi-no-secboot.xml          |  20 ++
 ...irmware-auto-efi-nvram.x86_64-latest.args} |  10 +-
 .../firmware-auto-efi-nvram.xml               |  18 ++
 ...mware-auto-efi-secboot.x86_64-latest.args} |   8 +-
 .../firmware-auto-efi-secboot.xml             |  20 ++
 ...s => firmware-auto-efi.x86_64-latest.args} |   8 +-
 tests/qemuxml2argvdata/firmware-auto-efi.xml  |  17 ++
 ...anual-bios-rw-implicit.x86_64-latest.args} |   8 +-
 ...l => firmware-manual-bios-rw-implicit.xml} |   7 +-
 ...irmware-manual-bios-rw.x86_64-latest.args} |   8 +-
 ...o-path.xml => firmware-manual-bios-rw.xml} |   7 +-
 .../{bios.args => firmware-manual-bios.args}  |  11 +-
 .../qemuxml2argvdata/firmware-manual-bios.xml |  15 ++
 ... => firmware-manual-efi-acpi-aarch64.args} |   1 -
 ...l => firmware-manual-efi-acpi-aarch64.xml} |   4 +-
 ...args => firmware-manual-efi-acpi-q35.args} |   1 -
 ...i.xml => firmware-manual-efi-acpi-q35.xml} |   4 +-
 ...ware-manual-efi-features.x86_64-latest.err |   1 +
 ...e.xml => firmware-manual-efi-features.xml} |  12 +-
 ...th.err => firmware-manual-efi-no-path.err} |   0
 ...th.xml => firmware-manual-efi-no-path.xml} |   5 +-
 ...> firmware-manual-efi-noacpi-aarch64.args} |   1 -
 ...=> firmware-manual-efi-noacpi-aarch64.xml} |   4 +-
 ...err => firmware-manual-efi-noacpi-q35.err} |   0
 ...xml => firmware-manual-efi-noacpi-q35.xml} |   4 +-
 ...-manual-efi-nvram-file.x86_64-latest.args} |   4 +-
 ...xml => firmware-manual-efi-nvram-file.xml} |   6 +-
 ...-efi-nvram-network-iscsi.x86_64-4.1.0.err} |   0
 ...fi-nvram-network-iscsi.x86_64-latest.args} |   4 +-
 ...rmware-manual-efi-nvram-network-iscsi.xml} |   9 +-
 ...-efi-nvram-network-nbd.x86_64-latest.args} |   4 +-
 ...firmware-manual-efi-nvram-network-nbd.xml} |   9 +-
 ...ual-efi-nvram-template.x86_64-latest.args} |   4 +-
 ...=> firmware-manual-efi-nvram-template.xml} |   6 +-
 ...e.args => firmware-manual-efi-secure.args} |   9 +-
 ...efi.xml => firmware-manual-efi-secure.xml} |  11 +-
 ...os-nvram.args => firmware-manual-efi.args} |   7 +-
 ...m-template.xml => firmware-manual-efi.xml} |   8 +-
 ...=> firmware-manual-noefi-acpi-aarch64.err} |   0
 ...=> firmware-manual-noefi-acpi-aarch64.xml} |   7 +-
 ...gs => firmware-manual-noefi-acpi-q35.args} |   4 -
 ...xml => firmware-manual-noefi-acpi-q35.xml} |   7 +-
 ...firmware-manual-noefi-noacpi-aarch64.args} |   4 -
 ... firmware-manual-noefi-noacpi-aarch64.xml} |   7 +-
 ... => firmware-manual-noefi-noacpi-q35.args} |   4 -
 ...l => firmware-manual-noefi-noacpi-q35.xml} |   7 +-
 tests/qemuxml2argvdata/os-firmware-bios.xml   |  68 -------
 .../os-firmware-efi-secboot.xml               |  68 -------
 tests/qemuxml2argvdata/os-firmware-efi.xml    |  68 -------
 .../pci-bridge-many-disks.args                |   1 -
 .../pci-bridge-many-disks.xml                 |   1 -
 .../virtio-iommu-aarch64.aarch64-latest.args  |   2 +-
 .../qemuxml2argvdata/virtio-iommu-aarch64.xml |   6 +-
 tests/qemuxml2argvtest.c                      |  61 +++---
 .../bios-nvram-os-interleave.xml              |  52 -----
 tests/qemuxml2xmloutdata/bios-nvram.xml       |  44 -----
 .../firmware-auto-bios.x86_64-latest.xml}     |  23 +--
 ...mware-auto-efi-aarch64.aarch64-latest.xml} |  12 +-
 ...-auto-efi-enrolled-keys.x86_64-latest.xml} |  21 +-
 ...-auto-efi-loader-secure.x86_64-latest.xml} |  22 +--
 ...to-efi-no-enrolled-keys.x86_64-latest.xml} |  18 +-
 ...are-auto-efi-no-secboot.x86_64-latest.xml} |  20 +-
 ...firmware-auto-efi-nvram.x86_64-latest.xml} |  22 +--
 ...rmware-auto-efi-secboot.x86_64-latest.xml} |  20 +-
 .../firmware-auto-efi.x86_64-latest.xml}      |  21 +-
 ...e-manual-efi-nvram-file.x86_64-latest.xml} |   9 +-
 ...efi-nvram-network-iscsi.x86_64-latest.xml} |  11 +-
 ...l-efi-nvram-network-nbd.x86_64-latest.xml} |  11 +-
 .../firmware-manual-efi.xml}                  |  15 +-
 .../os-firmware-bios.x86_64-latest.xml        |  72 -------
 ...are-efi-no-enrolled-keys.x86_64-latest.xml |   1 -
 .../os-firmware-efi-secboot.x86_64-latest.xml |  72 -------
 .../os-firmware-efi.x86_64-latest.xml         |  72 -------
 .../pci-bridge-many-disks.xml                 |   1 -
 .../virtio-iommu-aarch64.aarch64-latest.xml   |   6 +-
 tests/qemuxml2xmltest.c                       |  25 +--
 109 files changed, 708 insertions(+), 1282 deletions(-)
 create mode 100644 docs/kbase/secureboot.rst
 delete mode 100644 tests/qemuxml2argvdata/aarch64-os-firmware-efi.xml
 delete mode 100644 tests/qemuxml2argvdata/bios-nvram-os-interleave.xml
 delete mode 100644 tests/qemuxml2argvdata/bios-nvram-rw-implicit.xml
 delete mode 100644 tests/qemuxml2argvdata/bios-nvram-rw.xml
 delete mode 100644 tests/qemuxml2argvdata/bios-nvram-secure.xml
 delete mode 100644 tests/qemuxml2argvdata/bios.xml
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-bios-nvram.x86_64-latest.err
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-bios-nvram.xml
 rename tests/qemuxml2argvdata/{os-firmware-bios.x86_64-latest.args => firmware-auto-bios.x86_64-latest.args} (55%)
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-bios.xml
 rename tests/qemuxml2argvdata/{aarch64-os-firmware-efi.aarch64-latest.args => firmware-auto-efi-aarch64.aarch64-latest.args} (91%)
 copy tests/qemuxml2argvdata/{aarch64-acpi-uefi.xml => firmware-auto-efi-aarch64.xml} (53%)
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-enrolled-keys-no-secboot.x86_64-latest.err
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-enrolled-keys-no-secboot.xml
 rename tests/qemuxml2argvdata/{os-firmware-efi-secboot.x86_64-latest.args => firmware-auto-efi-enrolled-keys.x86_64-latest.args} (60%)
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-enrolled-keys.xml
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-loader-insecure.x86_64-latest.err
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-loader-insecure.xml
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-loader-path.x86_64-latest.err
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-loader-path.xml
 rename tests/qemuxml2argvdata/{os-firmware-efi.x86_64-latest.args => firmware-auto-efi-loader-secure.x86_64-latest.args} (59%)
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-loader-secure.xml
 copy tests/qemuxml2argvdata/{os-firmware-efi-no-enrolled-keys.x86_64-latest.args => firmware-auto-efi-no-enrolled-keys.x86_64-latest.args} (84%)
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-no-enrolled-keys.xml
 copy tests/qemuxml2argvdata/{os-firmware-efi-no-enrolled-keys.x86_64-latest.args => firmware-auto-efi-no-secboot.x86_64-latest.args} (84%)
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-no-secboot.xml
 copy tests/qemuxml2argvdata/{os-firmware-efi-no-enrolled-keys.x86_64-latest.args => firmware-auto-efi-nvram.x86_64-latest.args} (65%)
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-nvram.xml
 copy tests/qemuxml2argvdata/{os-firmware-efi-no-enrolled-keys.x86_64-latest.args => firmware-auto-efi-secboot.x86_64-latest.args} (73%)
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi-secboot.xml
 rename tests/qemuxml2argvdata/{os-firmware-efi-no-enrolled-keys.x86_64-latest.args => firmware-auto-efi.x86_64-latest.args} (73%)
 create mode 100644 tests/qemuxml2argvdata/firmware-auto-efi.xml
 rename tests/qemuxml2argvdata/{bios-nvram-rw.x86_64-latest.args => firmware-manual-bios-rw-implicit.x86_64-latest.args} (68%)
 copy tests/qemuxml2argvdata/{bios-nvram-no-path.xml => firmware-manual-bios-rw-implicit.xml} (70%)
 rename tests/qemuxml2argvdata/{bios-nvram-rw-implicit.x86_64-latest.args => firmware-manual-bios-rw.x86_64-latest.args} (68%)
 copy tests/qemuxml2argvdata/{bios-nvram-no-path.xml => firmware-manual-bios-rw.xml} (68%)
 rename tests/qemuxml2argvdata/{bios.args => firmware-manual-bios.args} (65%)
 create mode 100644 tests/qemuxml2argvdata/firmware-manual-bios.xml
 rename tests/qemuxml2argvdata/{aarch64-acpi-uefi.args => firmware-manual-efi-acpi-aarch64.args} (98%)
 rename tests/qemuxml2argvdata/{aarch64-acpi-uefi.xml => firmware-manual-efi-acpi-aarch64.xml} (89%)
 rename tests/qemuxml2argvdata/{q35-acpi-uefi.args => firmware-manual-efi-acpi-q35.args} (98%)
 copy tests/qemuxml2argvdata/{q35-acpi-uefi.xml => firmware-manual-efi-acpi-q35.xml} (90%)
 create mode 100644 tests/qemuxml2argvdata/firmware-manual-efi-features.x86_64-latest.err
 copy tests/qemuxml2argvdata/{bios-nvram-template.xml => firmware-manual-efi-features.xml} (67%)
 rename tests/qemuxml2argvdata/{bios-nvram-no-path.err => firmware-manual-efi-no-path.err} (100%)
 rename tests/qemuxml2argvdata/{bios-nvram-no-path.xml => firmware-manual-efi-no-path.xml} (79%)
 rename tests/qemuxml2argvdata/{aarch64-noacpi-uefi.args => firmware-manual-efi-noacpi-aarch64.args} (98%)
 rename tests/qemuxml2argvdata/{aarch64-noacpi-uefi.xml => firmware-manual-efi-noacpi-aarch64.xml} (88%)
 rename tests/qemuxml2argvdata/{q35-noacpi-uefi.err => firmware-manual-efi-noacpi-q35.err} (100%)
 rename tests/qemuxml2argvdata/{q35-noacpi-uefi.xml => firmware-manual-efi-noacpi-q35.xml} (89%)
 rename tests/qemuxml2argvdata/{bios-nvram-file.x86_64-latest.args => firmware-manual-efi-nvram-file.x86_64-latest.args} (89%)
 rename tests/qemuxml2argvdata/{bios-nvram-file.xml => firmware-manual-efi-nvram-file.xml} (81%)
 rename tests/qemuxml2argvdata/{bios-nvram-network-iscsi.x86_64-4.1.0.err => firmware-manual-efi-nvram-network-iscsi.x86_64-4.1.0.err} (100%)
 rename tests/qemuxml2argvdata/{bios-nvram-network-iscsi.x86_64-latest.args => firmware-manual-efi-nvram-network-iscsi.x86_64-latest.args} (91%)
 rename tests/qemuxml2argvdata/{bios-nvram-network-iscsi.xml => firmware-manual-efi-nvram-network-iscsi.xml} (76%)
 rename tests/qemuxml2argvdata/{bios-nvram-network-nbd.x86_64-latest.args => firmware-manual-efi-nvram-network-nbd.x86_64-latest.args} (89%)
 rename tests/qemuxml2argvdata/{bios-nvram-network-nbd.xml => firmware-manual-efi-nvram-network-nbd.xml} (72%)
 rename tests/qemuxml2argvdata/{bios-nvram-template.x86_64-latest.args => firmware-manual-efi-nvram-template.x86_64-latest.args} (89%)
 copy tests/qemuxml2argvdata/{bios-nvram-template.xml => firmware-manual-efi-nvram-template.xml} (79%)
 rename tests/qemuxml2argvdata/{bios-nvram-secure.args => firmware-manual-efi-secure.args} (67%)
 rename tests/qemuxml2argvdata/{q35-acpi-uefi.xml => firmware-manual-efi-secure.xml} (60%)
 rename tests/qemuxml2argvdata/{bios-nvram.args => firmware-manual-efi.args} (76%)
 rename tests/qemuxml2argvdata/{bios-nvram-template.xml => firmware-manual-efi.xml} (71%)
 rename tests/qemuxml2argvdata/{aarch64-acpi-nouefi.err => firmware-manual-noefi-acpi-aarch64.err} (100%)
 rename tests/qemuxml2argvdata/{aarch64-acpi-nouefi.xml => firmware-manual-noefi-acpi-aarch64.xml} (61%)
 rename tests/qemuxml2argvdata/{q35-acpi-nouefi.args => firmware-manual-noefi-acpi-q35.args} (84%)
 rename tests/qemuxml2argvdata/{q35-acpi-nouefi.xml => firmware-manual-noefi-acpi-q35.xml} (63%)
 rename tests/qemuxml2argvdata/{aarch64-noacpi-nouefi.args => firmware-manual-noefi-noacpi-aarch64.args} (83%)
 rename tests/qemuxml2argvdata/{aarch64-noacpi-nouefi.xml => firmware-manual-noefi-noacpi-aarch64.xml} (59%)
 rename tests/qemuxml2argvdata/{q35-noacpi-nouefi.args => firmware-manual-noefi-noacpi-q35.args} (84%)
 rename tests/qemuxml2argvdata/{q35-noacpi-nouefi.xml => firmware-manual-noefi-noacpi-q35.xml} (60%)
 delete mode 100644 tests/qemuxml2argvdata/os-firmware-bios.xml
 delete mode 100644 tests/qemuxml2argvdata/os-firmware-efi-secboot.xml
 delete mode 100644 tests/qemuxml2argvdata/os-firmware-efi.xml
 delete mode 100644 tests/qemuxml2xmloutdata/bios-nvram-os-interleave.xml
 delete mode 100644 tests/qemuxml2xmloutdata/bios-nvram.xml
 copy tests/{qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.xml => qemuxml2xmloutdata/firmware-auto-bios.x86_64-latest.xml} (55%)
 rename tests/qemuxml2xmloutdata/{aarch64-os-firmware-efi.aarch64-latest.xml => firmware-auto-efi-aarch64.aarch64-latest.xml} (71%)
 copy tests/{qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.xml => qemuxml2xmloutdata/firmware-auto-efi-enrolled-keys.x86_64-latest.xml} (58%)
 copy tests/{qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.xml => qemuxml2xmloutdata/firmware-auto-efi-loader-secure.x86_64-latest.xml} (57%)
 copy tests/{qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.xml => qemuxml2xmloutdata/firmware-auto-efi-no-enrolled-keys.x86_64-latest.xml} (61%)
 copy tests/{qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.xml => qemuxml2xmloutdata/firmware-auto-efi-no-secboot.x86_64-latest.xml} (58%)
 copy tests/{qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.xml => qemuxml2xmloutdata/firmware-auto-efi-nvram.x86_64-latest.xml} (57%)
 copy tests/{qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.xml => qemuxml2xmloutdata/firmware-auto-efi-secboot.x86_64-latest.xml} (58%)
 rename tests/{qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.xml => qemuxml2xmloutdata/firmware-auto-efi.x86_64-latest.xml} (57%)
 rename tests/qemuxml2xmloutdata/{bios-nvram-file.x86_64-latest.xml => firmware-manual-efi-nvram-file.x86_64-latest.xml} (75%)
 rename tests/qemuxml2xmloutdata/{bios-nvram-network-iscsi.x86_64-latest.xml => firmware-manual-efi-nvram-network-iscsi.x86_64-latest.xml} (76%)
 rename tests/qemuxml2xmloutdata/{bios-nvram-network-nbd.x86_64-latest.xml => firmware-manual-efi-nvram-network-nbd.x86_64-latest.xml} (74%)
 rename tests/{qemuxml2argvdata/bios-nvram.xml => qemuxml2xmloutdata/firmware-manual-efi.xml} (65%)
 delete mode 100644 tests/qemuxml2xmloutdata/os-firmware-bios.x86_64-latest.xml
 delete mode 120000 tests/qemuxml2xmloutdata/os-firmware-efi-no-enrolled-keys.x86_64-latest.xml
 delete mode 100644 tests/qemuxml2xmloutdata/os-firmware-efi-secboot.x86_64-latest.xml
 delete mode 100644 tests/qemuxml2xmloutdata/os-firmware-efi.x86_64-latest.xml

-- 
2.35.3

On 6/23/22 18:14, Andrea Bolognani wrote:
> The main motivation behind this series was making it as simple as
> possible ("one click") to enable Secure Boot for a VM.
> 
> In the process I ended up fixing, improving and cleaning up various
> parts of the firmware selection interface.
> 
> GitLab branch: https://gitlab.com/abologna/libvirt/-/commits/firmware
> Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/571485540
> 
> Andrea Bolognani (28):
>   tests: Remove firmware bits from unrelated tests
>   tests: Use firmware autoselection on aarch64
>   tests: Drop bios-nvram-os-interleave test
>   tests: Rename and reorganize firmware tests
>   tests: Use minimal hardware for firmware tests
>   tests: Don't set NVRAM path manually
>   tests: Don't use loader.secure=no with firmware autoselection
>   tests: Add more firmware tests
>   conf: Move virDomainLoaderDefParseXML()
>   conf: Rename virDomainLoaderDefParseXMLNvram()
>   conf: Move setting type for NVRAM source
>   conf: Move nvramTemplate parsing
>   conf: Handle NVRAM in virDomainLoaderDefParseXML()
>   conf: Rename virDomainLoaderDefParseXML() argument
>   conf: Use nodes in virDomainLoaderDefParseXMLNvram()
>   conf: Always parse NVRAM path if present
>   conf: Enable secure-boot when enrolled-keys is enabled
>   conf: Add return value to virDomainDefPostParseOs()
>   conf: Reject enrolled-keys=yes with secure-boot=no
>   conf: Always parse all firmware information
>   conf: Refactor virDomainDefOSValidate()
>   conf: Validate firmware configuration more thoroughly
>   conf: Always parse firmware features
>   conf: Reject features when using manual firmware selection
>   qemu_firmware: Enable loader.secure when requires-smm
>   qemu_firmware: enrolled-keys requires secure-boot
>   docs: Add kbase page for Secure Boot
>   NEWS: Document improvements to firmware autoselection
> 

>  109 files changed, 708 insertions(+), 1282 deletions(-)

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>

On Thu, Jun 23, 2022 at 06:14:12PM +0200, Andrea Bolognani wrote:
> The main motivation behind this series was making it as simple as
> possible ("one click") to enable Secure Boot for a VM.

Heads up, and sort-of follow-up to the recent secure boot and smm (x86)
and tz (arm) discussion.

We'll most likely get a new secure boot variant soon.  This will not
require smm, but it will also not support persistent variables.  The
underlying idea is to simply re-initialize the variable store from
known-good ROM on each boot to compensate for the varstore not being
protected against the guest OS tampering with it.

Which of course implies some drawbacks:  The guest can't add keys (via
mokutil) for example, and turning off secure boot in firmware setup
wouldn't work either.  There are enough use cases (like just booting
cloud images in secure boot mode) where this doesn't matter, so I
consider this useful nevertheless, but maybe a separate feature flag
like 'stateless-secure-boot' makes sense for that.

Not sure yet how to package that up, best is probably as stateless image
because that'll reduce the chances of getting it wrong, i.e. something
like this:

{
    "description": "OVMF with secure boot, no persistent vars",
    "interface-types": [
        "uefi"
    ],
    "mapping": {
        "device": "flash",
        "mode": "stateless",
        "executable": {
            "filename": "/usr/share/edk2/ovmf/OVMF.secboot.fd",
            "format": "raw"
        }
    },
    "targets": [
        {
            "architecture": "x86_64",
            "machines": [
                "pc-i440fx-*"
                "pc-q35-*"
            ]
        }
    ],
    "features": [
        "secure-boot",
        "enrolled-keys",
    ]
}

The idea idea should work for aarch64 too and remove the trustzone support
requirement.

take care,
  Gerd

On Mon, Jun 27, 2022 at 12:00:59PM +0200, Gerd Hoffmann wrote:
> On Thu, Jun 23, 2022 at 06:14:12PM +0200, Andrea Bolognani wrote:
> > The main motivation behind this series was making it as simple as
> > possible ("one click") to enable Secure Boot for a VM.
> 
> Heads up, and sort-of follow-up to the recent secure boot and smm (x86)
> and tz (arm) discussion.
> 
> We'll most likely get a new secure boot variant soon.  This will not
> require smm, but it will also not support persistent variables.  The
> underlying idea is to simply re-initialize the variable store from
> known-good ROM on each boot to compensate for the varstore not being
> protected against the guest OS tampering with it.
> 
> Which of course implies some drawbacks:  The guest can't add keys (via
> mokutil) for example, and turning off secure boot in firmware setup
> wouldn't work either.  There are enough use cases (like just booting
> cloud images in secure boot mode) where this doesn't matter, so I
> consider this useful nevertheless, but maybe a separate feature flag
> like 'stateless-secure-boot' makes sense for that.

Since the use case will be virt related, there's always the possibility
of using host side tools to inject a custom key into the default varstore
before the guest OS runs. That doesn't cover all possible mokutil
scenarios, but at least addresses the big one of providing a firmware
that trusts the user's keys, instead of the OS vendor keys.

I don't think we need a 'stateles-secure-boot' flag, as thats
implicit from mapping.mode=statusless and features.secure-boot

> Not sure yet how to package that up, best is probably as stateless image
> because that'll reduce the chances of getting it wrong, i.e. something
> like this:
> 
> {
>     "description": "OVMF with secure boot, no persistent vars",
>     "interface-types": [
>         "uefi"
>     ],
>     "mapping": {
>         "device": "flash",
>         "mode": "stateless",
>         "executable": {
>             "filename": "/usr/share/edk2/ovmf/OVMF.secboot.fd",
>             "format": "raw"
>         }
>     },
>     "targets": [
>         {
>             "architecture": "x86_64",
>             "machines": [
>                 "pc-i440fx-*"
>                 "pc-q35-*"
>             ]
>         }
>     ],
>     "features": [
>         "secure-boot",
>         "enrolled-keys",
>     ]
> }

This looks reasonable.

> 
> The idea idea should work for aarch64 too and remove the trustzone support
> requirement.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On Mon, Jun 27, 2022 at 11:07:35AM +0100, Daniel P. Berrangé wrote:
> On Mon, Jun 27, 2022 at 12:00:59PM +0200, Gerd Hoffmann wrote:
> > On Thu, Jun 23, 2022 at 06:14:12PM +0200, Andrea Bolognani wrote:
> > > The main motivation behind this series was making it as simple as
> > > possible ("one click") to enable Secure Boot for a VM.
> >
> > Heads up, and sort-of follow-up to the recent secure boot and smm (x86)
> > and tz (arm) discussion.

Thanks for the heads up, Gerd!

> > We'll most likely get a new secure boot variant soon.  This will not
> > require smm, but it will also not support persistent variables.  The
> > underlying idea is to simply re-initialize the variable store from
> > known-good ROM on each boot to compensate for the varstore not being
> > protected against the guest OS tampering with it.
> >
> > Which of course implies some drawbacks:  The guest can't add keys (via
> > mokutil) for example, and turning off secure boot in firmware setup
> > wouldn't work either.  There are enough use cases (like just booting
> > cloud images in secure boot mode) where this doesn't matter, so I
> > consider this useful nevertheless, but maybe a separate feature flag
> > like 'stateless-secure-boot' makes sense for that.
>
> Since the use case will be virt related, there's always the possibility
> of using host side tools to inject a custom key into the default varstore
> before the guest OS runs. That doesn't cover all possible mokutil
> scenarios, but at least addresses the big one of providing a firmware
> that trusts the user's keys, instead of the OS vendor keys.
>
> I don't think we need a 'stateles-secure-boot' flag, as thats
> implicit from mapping.mode=statusless and features.secure-boot

We don't currently offer a way to filter firmware builds based on
their mode. So on a machine where this new firmware is available, a
VM configuration like

  <os firmware='efi'>
    <firmware>
      <feature enabled='yes' name='secure-boot'/>
      <feature enabled='yes' name='enrolled-keys'/>
    </firmware>
  </os>

might result in either a firmware with writable variables or a
stateless one being selected. If the user's expectation is that they
will be able to use mokutil inside the VM, the latter will not make
them happy.

If we had a separate feature, one could use

  <os firmware='efi'>
    <firmware>
      <feature enabled='no' name='stateless'/>
      <feature enabled='yes' name='secure-boot'/>
      <feature enabled='yes' name='enrolled-keys'/>
    </firmware>
  </os>

to ensure mokutils can be used.

Maybe we can make the mode filterable instead? Like

  <os firmware='efi'>
    <firmware>
      <mode name='split'/>
      <feature enabled='yes' name='secure-boot'/>
      <feature enabled='yes' name='enrolled-keys'/>
    </firmware>
  </os>

or something along those lines.

> > Not sure yet how to package that up, best is probably as stateless image
> > because that'll reduce the chances of getting it wrong, i.e. something
> > like this:
> >
> > {
> >     "description": "OVMF with secure boot, no persistent vars",
> >     "interface-types": [
> >         "uefi"
> >     ],
> >     "mapping": {
> >         "device": "flash",
> >         "mode": "stateless",
> >         "executable": {
> >             "filename": "/usr/share/edk2/ovmf/OVMF.secboot.fd",

Just to be clear: the firmware build supporting this new, stateless
style of Secure Boot would be a completely separate one from the
existing OVMF.secboot.fd, right?

> > The idea idea should work for aarch64 too and remove the trustzone support
> > requirement.

Yeah, that'd be a pretty great outcome :)

-- 
Andrea Bolognani / Red Hat / Virtualization

On Mon, Jun 27, 2022 at 09:04:02AM -0700, Andrea Bolognani wrote:
> On Mon, Jun 27, 2022 at 11:07:35AM +0100, Daniel P. Berrangé wrote:
> > On Mon, Jun 27, 2022 at 12:00:59PM +0200, Gerd Hoffmann wrote:
> > > On Thu, Jun 23, 2022 at 06:14:12PM +0200, Andrea Bolognani wrote:
> > > > The main motivation behind this series was making it as simple as
> > > > possible ("one click") to enable Secure Boot for a VM.
> > >
> > > Heads up, and sort-of follow-up to the recent secure boot and smm (x86)
> > > and tz (arm) discussion.
> 
> Thanks for the heads up, Gerd!
> 
> > > We'll most likely get a new secure boot variant soon.  This will not
> > > require smm, but it will also not support persistent variables.  The
> > > underlying idea is to simply re-initialize the variable store from
> > > known-good ROM on each boot to compensate for the varstore not being
> > > protected against the guest OS tampering with it.
> > >
> > > Which of course implies some drawbacks:  The guest can't add keys (via
> > > mokutil) for example, and turning off secure boot in firmware setup
> > > wouldn't work either.  There are enough use cases (like just booting
> > > cloud images in secure boot mode) where this doesn't matter, so I
> > > consider this useful nevertheless, but maybe a separate feature flag
> > > like 'stateless-secure-boot' makes sense for that.
> >
> > Since the use case will be virt related, there's always the possibility
> > of using host side tools to inject a custom key into the default varstore
> > before the guest OS runs. That doesn't cover all possible mokutil
> > scenarios, but at least addresses the big one of providing a firmware
> > that trusts the user's keys, instead of the OS vendor keys.
> >
> > I don't think we need a 'stateles-secure-boot' flag, as thats
> > implicit from mapping.mode=statusless and features.secure-boot
> 
> We don't currently offer a way to filter firmware builds based on
> their mode. So on a machine where this new firmware is available, a
> VM configuration like
> 
>   <os firmware='efi'>
>     <firmware>
>       <feature enabled='yes' name='secure-boot'/>
>       <feature enabled='yes' name='enrolled-keys'/>
>     </firmware>
>   </os>
> 
> might result in either a firmware with writable variables or a
> stateless one being selected. If the user's expectation is that they
> will be able to use mokutil inside the VM, the latter will not make
> them happy.
> 
> If we had a separate feature, one could use
> 
>   <os firmware='efi'>
>     <firmware>
>       <feature enabled='no' name='stateless'/>
>       <feature enabled='yes' name='secure-boot'/>
>       <feature enabled='yes' name='enrolled-keys'/>
>     </firmware>
>   </os>
> 
> to ensure mokutils can be used.
> 
> Maybe we can make the mode filterable instead? Like
> 
>   <os firmware='efi'>
>     <firmware>
>       <mode name='split'/>
>       <feature enabled='yes' name='secure-boot'/>
>       <feature enabled='yes' name='enrolled-keys'/>
>     </firmware>
>   </os>
> 
> or something along those lines.

This is the wrong place to be configuring it, as this is actually
a guest ABI issue.  What we need is to express that a given VM
configuration must not have NVRAM present, and this is independant
of firmware feature selection

IOW, we need

   <os ...>
      ....
      <nvram present="yes|no"/>
      ...
   </os>

this is something I have a PoC for for AMD SEV, but still have some
tidying up to do. Essentially if NVRAM is set as not present, then
we would only match firmware descriptors with mode=stateless


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|