Re: [libvirt] [qemu RFC v2] qapi: add "firmware.json"
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