From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f8mdm-0007Gj-FL for qemu-devel@nongnu.org; Wed, 18 Apr 2018 08:56:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f8mdi-0001xZ-Kp for qemu-devel@nongnu.org; Wed, 18 Apr 2018 08:56:50 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:59024 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 1f8mdi-0001x4-Gg for qemu-devel@nongnu.org; Wed, 18 Apr 2018 08:56:46 -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> From: Laszlo Ersek Message-ID: Date: Wed, 18 Apr 2018 14:56:34 +0200 MIME-Version: 1.0 In-Reply-To: <20180418122312.ebmd2nrtvk2h5e45@sirius.home.kraxel.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [qemu RFC v2] qapi: add "firmware.json" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: "Daniel P. Berrange" , 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 14:23, Gerd Hoffmann wrote: > Hi, > >> Hmmm, I'm not sure I agree. One use case is that you want a domain >> config in which well-known OS-es, signed by the MS UEFI certs, just boot >> with SB enabled. (Some of our internal folks really want this.) >> >> Another use case is that you want a domain in which SB *can* be enabled, >> but your installer is signed with a different certificate chain (or it >> is unsigned), and with *just* the MS certs enrolled, it wouldn't boot at >> all. So you want the SB *feature*, but definitely not the initial >> enrollment / SB *operational mode*. > > So "secure-boot-enrolled-keys" also has SB turned on. Yes. >> For me to understand you better, are you suggesting merely that I: >> >> - rename @secure-boot-enrolled-keys to @enrolled-keys, and >> >> - drop the reference to @secure-boot from the end of the @enrolled-keys >> documentation paragraph? (Namely, "@secure-boot-enrolled-keys is only >> valid if the firmware also supports @secure-boot"). > > Yes. So "secure-boot" specifies "firmware binary supports secure-boot" > and "enrolled-keys" specifies "firmware nvram template has keys enrolled > (and SB enabled). OK. > 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? > then specify > "'enrolled-keys' : 'Microsoft'" in the json file. If this is really necessary (up to Dan :) ), I'm down with it. Thanks Laszlo