Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json"

[Laszlo Ersek]

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/address@hidden

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