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