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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
