On 04/18/18 08:02, Gerd Hoffmann wrote:
On Wed, Apr 18, 2018 at 12:40:54AM +0200, Laszlo Ersek wrote:
Add a schema that describes the different uses and properties of virtual machine firmware.
Looks good to me overall.
+{ 'enum' : 'FirmwareType', + 'data' : [ 'bios', 'slof', 'uboot', 'uefi' ] }
openbios missing.
+{ 'enum' : 'FirmwareArchitecture', + 'data' : [ 'aarch64', 'arm', 'i386', 'x86_64' ] }
ppc(64) missing (but you have slof above ;) ... s390 too.
I figured those would be contributed by people that actually use them, as separate patches :) In fact I would rather prefer removing "slof" and "uboot" from this initial version, because I have zero clue about them. Of course, if reviewers can tell me what *exact* enum constants I should add, I'll comply.
+# @machines: Lists the machine types (known by the emulator that is specified +# through @architecture) that can execute the firmware. Elements of +# @machines are not supposed to be versioned; if a machine type is +# versioned in QEMU (e.g. "pc-i440fx-2.12"), then its unversioned +# variant, which typically refers to the latest version (e.g. "pc"), +# should be listed in @machines. On the QEMU command line, "-machine +# type=..." specifies the requested machine type.
Hmm, I'd tend to ignore the aliases here (pc, q35, virt) and use wildcards instead (pc-i440fx-*, pc-q35-*, virt-*).
I think that will be easier for libvirt to work with because it always resolves aliases to actual machine types when storing them in the domain xml.
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.
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. For example, if you try to run "EnrollDefaultKeys.efi" on an OVMF that was built without SB, you get:
FS1:\> EnrollDefaultKeys.efi error: GetVariable("SetupMode", 8BE4DF61-93CA-11D2-AA0D-00E098032B8C): Not Found
In other words, I don't see any use in a @Firmware element where @nvram_template had the SB operational mode enabled and certificates enrolled (hence listing the proposed @enrolled-keys in @features), while @executable lacked the SB feature itself (hence not listing @secure-boot in @features). In the first place, such a varstore file (to be saved as @nvram_template) could never be *established* from within the guest, using the @executable in question -- see the error message above. Thanks! Laszlo