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

[Dimitri John Ledkov]

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 <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.
> 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