From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f8ng5-0002rL-EL for qemu-devel@nongnu.org; Wed, 18 Apr 2018 10:03:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f8ng2-00076E-5H for qemu-devel@nongnu.org; Wed, 18 Apr 2018 10:03:17 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:46898 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f8ng1-00075s-W3 for qemu-devel@nongnu.org; Wed, 18 Apr 2018 10:03:14 -0400 References: <20180417224054.26363-1-lersek@redhat.com> <20180418060243.iafg4wj5gwsruop5@sirius.home.kraxel.org> <20180418090457.dqg5gxnzobdofkao@sirius.home.kraxel.org> <20180418122312.ebmd2nrtvk2h5e45@sirius.home.kraxel.org> <20180418130619.cmyyyl7fj2wfum7k@sirius.home.kraxel.org> <0545cc73-d821-c2d9-e4ab-938e58c34c2b@redhat.com> <20180418135344.GQ27579@redhat.com> From: Laszlo Ersek Message-ID: <9b760289-a92e-4ec0-ce3b-f13665b5799b@redhat.com> Date: Wed, 18 Apr 2018 16:03:03 +0200 MIME-Version: 1.0 In-Reply-To: <20180418135344.GQ27579@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "=?UTF-8?Q?Daniel_P._Berrang=c3=a9?=" Cc: Gerd Hoffmann , qemu-devel@nongnu.org, libvir-list@redhat.com, Alexander Graf , Ard Biesheuvel , David Gibson , Eric Blake , Gary Ching-Pang Lin , Kashyap Chamarthy , Markus Armbruster , Michael Roth , Michal Privoznik , Paolo Bonzini , Peter Krempa , Peter Maydell , Thomas Huth On 04/18/18 15:53, Daniel P. Berrang=C3=A9 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 an= y >>> 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 p= air: >> - 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-for= m >> strings. (Same issue as with @tags vs. @features.) >=20 > Ignoring secboot cert name for a minute, ultimately no matter what we d= o > in terms of metadata there is always going to be the possibility that > many firmware images all match the criteria libvirt is searching on. >=20 > Apps thus need rules to pick one of the many matches, and users need th= e > ability to override distro defaults. We can achieve that as follows: >=20 > 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 >=20 > Second, we should define three well known directory locations >=20 > - /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 addition= s) >=20 > 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 provide= d > file. A zero length file should be simply hide the distro provided file >=20 > So for example, distro ships >=20 > /usr/share/qemu/firmware/50-ovmf.json > /usr/share/qemu/firmware/50-seabios-256k.json >=20 > The sysadmin can now prevent the default ovmf being used at all with >=20 > $ touch /etc/qemu/firmware/50-ovmf.json >=20 > The sysadmin can replace/alter the distro default ovmf with >=20 > $ vim /etc/qemu/firmware/50-ovmf.json >=20 > Or they can provide a parallel ovmf with higher priority >=20 > $ vim /etc/qemu/firmware/10-ovmf.json >=20 > Or they can provide a parallel ovmf with lower priority >=20 > $ vim /etc/qemu/firmware/99-ovmf.json >=20 > $HOME/.config/qemu/firmware would take prior over /etc/qemu and > /usr/share/qemu.=20 >=20 >=20 > 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= . >=20 > The end user can provide their over ovmf with personal keys that replac= es > the distro microsoft enrolled one entirely, etc. >=20 > 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