On Fri, 23 Jun 2023 at 15:46, Tobias Powalowski <tobias.powalow...@googlemail.com> 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.
Apparently, SHIM hooks LoadImage and StartImage, but does not actually perform any verification against the MOK db in this case. This probably implies that upstream GRUB in its current state (without the EFI stub boot patches that the distros are carrying) should fallback to 'legacy' x86 EFI boot when secure boot is enabled and the shim lock verifier is active. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
