Hi, On Fri, 23 Jun 2023 at 14:46, Tobias Powalowski via Grub-devel <grub-devel@gnu.org> wrote: > > > > Am Fr., 23. Juni 2023 um 15:41 Uhr schrieb Ard Biesheuvel <a...@kernel.org>: >> >> On Thu, 22 Jun 2023 at 11:41, Tobias Powalowski >> <tobias.powalow...@googlemail.com> wrote: >> > >> > Hi tackled it down to this commit: >> > https://git.savannah.gnu.org/cgit/grub.git/commit/?id=6a080b9cde0be5d08b71daf17a806067e32fc13f >> > starting with this commit shim verification fails for kernel hash with bad >> > shim verification and makes Secure Boot impossible. >> >> Could you elaborate on your setup? How are you signing and >> authenticating the kernel image? >> >> GRUB calls LoadImage/StartImage, and these calls will be intercepted >> by shim to implement its own authentication. The expectation here is >> that the kernel's PE image is signed with a MOK key. > > Hi, > here is how it worked before: > Add the kernel and grub hashes through MOK manager. After adding those grub > was able to boot the hashed kernel. > On the installation medium I cannot expect someone already has a MOK > certificate, though hashes needs to be used in first place. > greetings > tpowa
Is the kernel image padded? is it unsigned? is it signed? If it is not signed, are you able to add any secureboot signature to it (i.e. sbsign it with a snakeoil cert), then compute the authenticode hash of it & enroll that hash into MOK and then does it become bootable? Note that authenticode of unpadded/unsigned EFI applications is unfortunately under defined and often buggy. -- okurrr, Dimitri _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
