Re: [libvirt] [qemu RFC v2] qapi: add "firmware.json"
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.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|