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