[libvirt] [qemu RFC v2] qapi: add "firmware.json"

Gerd Hoffmann kraxel at redhat.com
Wed Apr 18 09:04:57 UTC 2018


> This surfaced in the RFCv1 discussion, but Daniel suggested ignoring
> version numbers:
> 
> http://mid.mail-archive.com/20180410093412.GI5155@redhat.com
> 
> On 04/10/18 11:34, Daniel P. Berrangé wrote:
> > IMHO it would be valid to just keep life simple and only record the
> > base machine type name that can use the firmware ie "pc", "q35", and
> > ignore the fact that in some cases the firmware might require a
> > specific version of the machine type.

IIRC this bit referes to the fact that SMM requires qemu >= 2.x (don't
remember which x) to work.  So smm-enabled edk2 would just say
"pc-q35-*" instead of trying to specifying a version range somehow.

> Continuing:
> 
> On 04/18/18 08:02, Gerd Hoffmann wrote:
> >> +# @secure-boot: The firmware implements the software interfaces for UEFI Secure
> >> +#               Boot, as defined in the UEFI specification. Note that without
> >> +#               @requires-smm, guest code running with kernel privileges can
> >> +#               undermine the security of Secure Boot.
> >> +#
> >> +# @secure-boot-enrolled-keys: The variable store (NVRAM) template associated
> >
> > I think "enrolled-keys" should better be a separate feature.
> 
> It's not possible from the edk2 side; without -D SECURE_BOOT_ENABLE, the
> SB-related variables (SetupMode, PK, KEK, ...) don't work at all.

Sure.  The firmware builds will advertise both "secure-boot" and
"enrolled-keys" features to specify that.

But I think it should be enough to check for "secure-boot" feature to
figure whenever a given firmware build supports secure boot, not both
"secure-boot" and "secure-boot-plus-something-else".

cheers,
  Gerd




More information about the libvir-list mailing list