> Am 10.01.2019 um 09:12 schrieb Michael Chang <mch...@suse.com>: > > Hi, > > With the advent of new verifier framework and shim lock protocol support > to the grub's community, we are driving to the world of UEFI Secure > Boot, well, almost .. > > There is a missing piece in the puzzle remaining, that is booting linux > kernel via it's own EFI Handover Protocol's entry. Strictly speaking, > the interface is not part of the UEFI Secure Boot, but we have to use it > to avoid problem of using UEFI LoadImage Protocol, which will not work > with shim and it's Machine Owner Key (MOK) as they are not part of > firmware's KEK and db.
So really dumb question here: What if we didn't use the MS key? What if instead, we just provide a SUSE/openSUSE key and give customers the ability to sign their own grub+Linux binaries? Then we would only need to lobby with platform vendors to include our public key in the delivered Keystore in parallel and everything would "just work". The only reason shim needs to provide its own key management is that on most x86 systems, we (and customers) don't have control over the keystore, right? We can just push to not have that problem on ARM. Am I missing anything? Alex _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
