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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Apr 18, 2018 at 04:03:03PM +0200, Laszlo Ersek wrote:
> 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 be in whatever file ends up in the docs/specs directory eventually.

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

I think it is worth keeping the feature flag - we simply don't need
to say /what/ keys.

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

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 :|