On Fri, 23 Jun 2023 at 15:12, Ard Biesheuvel <a...@kernel.org> wrote: > > 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.
To be fair it should fail, as kernels typically do not have an SBAT section. > > 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. Which likely will become unusable going forward on x86 as well, when users and kernels rely on functionality only available via loadimage/startimage. -- okurrr, Dimitri _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel