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@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.
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
