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

[Ard Biesheuvel]

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.

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.