[libvirt] [qemu RFC v2] qapi: add "firmware.json"

[Laszlo Ersek]

On 04/18/18 11:04, Gerd Hoffmann wrote:
>> 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.
> 
> 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.

OK. I'm fine either way; Dan, can you please confirm you are OK with the
suggested wildcard format? (I.e., we still shouldn't include actual
version numbers in the supported machtypes list, but we should be more
specific than just "pc" and "q35" -- if the machine type is versioned,
use an asterisk for covering the version number.)

>> 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".

Hmmm, I'm not sure I agree. One use case is that you want a domain
config in which well-known OS-es, signed by the MS UEFI certs, just boot
with SB enabled. (Some of our internal folks really want this.)

Another use case is that you want a domain in which SB *can* be enabled,
but your installer is signed with a different certificate chain (or it
is unsigned), and with *just* the MS certs enrolled, it wouldn't boot at
all. So you want the SB *feature*, but definitely not the initial
enrollment / SB *operational mode*.

For me to understand you better, are you suggesting merely that I:

- rename @secure-boot-enrolled-keys to @enrolled-keys, and

- drop the reference to @secure-boot from the end of the @enrolled-keys
  documentation paragraph? (Namely, "@secure-boot-enrolled-keys is only
  valid if the firmware also supports @secure-boot").

Or are you suggesting something more?

Thanks!
Laszlo