Right now we're checking that firmware descriptor masking works
as intended by creating an empty file matching 60-ovmf-sb.json
in name.
However, that firmware descriptors contains the details for a
perfectly valid and quite common situation: Secure Boot being
supported by the firmware build, but being effectively disabled
by the lack of certificates in the NVRAM template.
Unmask that firmware descriptor, and instead create a dummy one
that has higher priority than all other OVMF builds and points
to paths that are obviously incorrect, which should make it
easy to notice it getting accidentally unmasked in the future.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we ignore all firmwares that are not in raw format
while performing autoselection, we can have descriptors for
firmware builds in QCOW2 format without breaking anything.
Note that the descriptors are arranged so that they have the
highest priority on aarch64, but the lowest one on x86_64.
This matches the expectation that QCOW2 will quickly be
adopted as the default on aarch64, where its use produces
significant benefits in terms of memory usage, while x86_64
will likely stick with raw for the foreseeable future.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently the 'nvram_template' entry is mandatory when parsing the
firmware descriptor based on flash. QEMU is extending the firmware
descriptor spec to make the 'nvram_template' optional, depending
on the value of a new 'mode' field:
- "split"
* "executable" contains read-only CODE
* "nvram_template" contains read-write VARS
- "combined"
* "executable" contains read-write CODE and VARs
* "nvram_template" not present
- "stateless"
* "executable" contains read-only CODE and VARs
* "nvram_template" not present
In the latter case, the guest OS can write vars but the
firmware will make no attempt to persist them, so any changes
will be lost at poweroff.
For now we parse this new 'mode' but discard any firmware
which is not 'mode=split' when matching for a domain.
In the tests we have a mixture of files with and without the
mode attribute.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
