> This surfaced in the RFCv1 discussion, but Daniel suggested ignoring > version numbers: > > http://mid.mail-archive.com/20180410093412.GI5155@xxxxxxxxxx > > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
