Re: Bad shim signature on kernel loading with patchset from 25.05.2023 and up

[Dimitri John Ledkov]

On Fri, 23 Jun 2023 at 15:12, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 23 Jun 2023 at 15:46, Tobias Powalowski
> <tobias.powalowski@googlemail.com> wrote:
> >
> >
> >
> > Am Fr., 23. Juni 2023 um 15:41 Uhr schrieb Ard Biesheuvel <ardb@kernel.org>:
> >>
> >> On Thu, 22 Jun 2023 at 11:41, Tobias Powalowski
> >> <tobias.powalowski@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