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

[Laszlo Ersek]

On 04/18/18 15:53, Daniel P. Berrangé wrote:
> On Wed, Apr 18, 2018 at 03:30:36PM +0200, Laszlo Ersek wrote:
>> On 04/18/18 15:06, Gerd Hoffmann wrote:
>>>>> Other question:  Do we want allow to specify which certs/keys are
>>>>> enrolled?  Which would probably mean to drop "enrolled-keys" from
>>>>> features and make it an optional string instead,
>>>>
>>>> Not an enum? "Microsoft" below should be an enum constant, shouldn't it?
>>>
>>> I don't think so.  If we want allow other certificate providers (not
>>> sure it makes sense as all physical hardware actually runs with the
>>> microsoft certificates), then we don't want a fixed list here.  So any
>>> CA can be listed, be it microsoft, redhat, canonical, verisign or
>>> kraxel.org ;)
>>
>> I agree (obviously), but then, at what detail do we stop?
>>
>> Because, if we go for full flexibility, then we should formalize:
>> - the certificate that goes into PK,
>> - the list of certificates that go into KEK,
>> - the list of certificates that go into db,
>>
>> and we should likely formalize "certificate" itself as the following pair:
>> - human-readable description (possibly the Common Name of the Subject),
>> - SHA256 digest (fingerprint) of the certificate.
>>
>> I do think this would totally be overkill, but I don't know where to
>> draw the line
>> - between the currently proposed @enrolled-keys (or similar enums that
>>   stand for well-defined "constellations")
>> - and the full details as described above.
>>
>> A simple string like "Microsoft" doesn't seem to me helpful for either
>> the user or management software -- the former won't know what
>> "Microsoft" stands for, and the latter won't want to look for free-form
>> strings. (Same issue as with @tags vs. @features.)
> 
> Ignoring secboot cert name for a minute, ultimately no matter what we do
> in terms of metadata there is always going to be the possibility that
> many firmware images all match the criteria libvirt is searching on.
> 
> Apps thus need rules to pick one of the many matches, and users need the
> ability to override distro defaults. We can achieve that as follows:
> 
> Recommend that firmware files are created with a double-digit prefix
> eg    50-ovmf.json  50-seabios-256k.json, etc, etc, so they can be
> sorted in predictable order
> 
> Second, we should define three well known directory locations
> 
>  - /usr/share/qemu/firmware  (used by distros packages)
>  - /etc/qemu/firmware  (exclusively for sysadmin local additions)
>  - $HOME/.config/qemu/firmware (exclusively for per-user local additions)
> 
> Apps like libvirt should build list of files from all three locations,
> then sort by filename.  If a local directory has a file with same
> name as the distro directory, then it should replace the distro provided
> file. A zero length file should be simply hide the distro provided file
> 
> So for example, distro ships
> 
>    /usr/share/qemu/firmware/50-ovmf.json
>    /usr/share/qemu/firmware/50-seabios-256k.json
> 
> The sysadmin can now prevent the default ovmf being used at all with
> 
>   $ touch /etc/qemu/firmware/50-ovmf.json
> 
> The sysadmin can replace/alter the distro default ovmf with
> 
>   $ vim /etc/qemu/firmware/50-ovmf.json
> 
> Or they can provide a parallel ovmf with higher priority
> 
>   $ vim /etc/qemu/firmware/10-ovmf.json
> 
> Or they can provide a parallel ovmf with lower priority
> 
>   $ vim /etc/qemu/firmware/99-ovmf.json
> 
> $HOME/.config/qemu/firmware would take prior over /etc/qemu and
> /usr/share/qemu. 
> 
> 
> Getting back to the question of many ovmf images with various different
> secboot keys. The distro can now provide many ovmf images each with
> different keys, if desired and determine which one is picked by default.
> 
> The end user can provide their over ovmf with personal keys that replaces
> the distro microsoft enrolled one entirely, etc.
> 
> IOW,  don't think we need to record which certs are use for secboot in
> the JSON metadata. Just lets overrides & ordering take care of it.

OK, thank you. Three more questions:

- Would you like me to capture the directory paths in the firmware.json
  file, or in the commit message for the patch?

- Should we keep @secure-boot-enrolled-keys (or, as Gerd suggests,
  @enrolled-keys) in the schema, as a feature enum constant, but remove
  the documentation of the actual certificates? (I.e., say "an
  unspecified set of certificates has been enrolled and SB mode has been
  enabled".)

- Or else, should we drop the feature flag that stands for enrollment
  completely?

Thanks,
Laszlo