[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] verifiers: Don't return error for deferred image

From: Zhang Boyang
Subject: Re: [PATCH] verifiers: Don't return error for deferred image
Date: Thu, 22 Dec 2022 22:37:01 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0


On 2022/12/22 20:22, Leo Yan wrote:
Hi Boyang,

On Thu, Dec 22, 2022 at 07:25:13PM +0800, Zhang Boyang wrote:

On 2022/12/22 19:14, Leo Yan wrote:
When boot from menu and the flag GRUB_VERIFY_FLAGS_DEFER_AUTH is set,
grub returns error:

   Booting a command list

   error: verification requested but nobody cares: (hd0,gpt1)/Image.

   Press any key to continue...

In this case, the image should be deferred for authentication, grub
should return the file handle and pass down to later firmware (e.g.
U-Boot, etc) for authentication.

This is probably not what verification framework designed to be. It seems to
be designed to verify files during GRUB is executing (e.g. check file
signature if UEFI Secure Boot is enabled).

Good point.  We expect the solution is grub can defer authentication for
an image and invokes EFI LoadImage service, then EFI loader can load
and verify the image.

Since you mentioned "authentication" and "verify", I guess you are using/implementing some kind of secure boot mechanism. Is it an standard UEFI Secure Boot implementation?

The standard UEFI Secure Boot for Linux works like this (at least on x86):

1) Firmware verifies and loads shim (shimx64.efi), which is signed by Microsoft. ( )

2) shim registers an EFI protocol, to provide an API for verifying files.

3) shim verifies and loads GRUB (grubx64.efi), using certificate embedded in itself. The certificate is generated by vendor (e.g. Debian).

4) GRUB opens kernel image file and loads and executes that file. The key point is, during grub_file_open() of the kernel image, the verifier framework will call shim lock verifier, which calls the API provided by shim, to verify the signature of kernel file. (grub-core/kern/efi/sb.c)

In the above example, the kernel is loaded by GRUB, not shim, not EFI firmware. GRUB calls the API provided by shim to verify the kernel.

Another example is GRUB can also chainload Windows:

1) 2) 3) is same

4) GRUB invokes EFI firmware's LoadFile() and StartImage(). The verification is completely delegated to EFI firmware. shim is not envolved.

In this example, the verification is done by EFI firmware, and GRUB/shim has no control of it. You can't even chainload GRUB itself because it's not signed by Microsoft.

For more specific, now I am debugging U-boot EFI with grub, since U-boot
EFI provides functionality for loading and authentication image (see
efi_load_image() in [1]), this is my purpose to use U-boot EFI to
authenticate kernel image (and even for initrd image).

It seems efi_load_image() is just a wrapper of EFI firmware's LoadFile() and there is no implementation of verification in U-boot?

I'd like to ask what kind of image you are trying to boot/execute? If it is an EFI application, I think you can "chainloader" it and forget U-boot (if U-boot have no verification in it self).

Let me guess: You are using standard Secure Boot, and want to boot linux kernel image directly signed by keys in EFI firmware, and your GRUB is installed with --disable-shim-lock. If this is what you are doing, you might run into the following situation:

1) During GRUB init, grub_efi_init() detects Secure Boot is enabled, so it calls grub_lockdown(). [grub-core/kern/efi/init.c]

2) grub_lockdown() registers lockdown verifier. [grub-core/kern/lockdown.c]

3) grub_efi_init() also calls grub_shim_lock_verifier_setup(). However, grub_shim_lock_verifier_setup() does nothing because of "--disable-shim-lock" [grub-core/kern/efi/sb.c]

4) During GRUB load linux kernel, the lockdown verifier sets a flag (GRUB_VERIFY_FLAGS_DEFER_AUTH) for kernel file, and expect shim lock verifier to do the verification.

5) However, there is no shim lock verifier. As a security measure, it reports the error "verification requested but nobody cares".

So the root cause seems like --disable-shim-lock is broken?

As a workaround, you can use shim: build shim for you platform and install GRUB with shim support.

You can also submit a fix to --disable-shim-lock (recommended). However it should be done very carefully. I'm afraid you can't remove the security measure (i.e. the "verification requested but nobody cares") directly. I think it is a good idea to add an EFI verifier (like shim verifier), which use LoadImage() to do verification, and enable it if (and only if) --disable-shim-lock is specified. You can talk to GRUB maintainers about your proposal before coding.

The above is what I guess about what's happening. It might be wrong. Please point out if there is something wrong.

By the way, I didn't understand what does "return the file handle and pass
down to later firmware" means. If you means you want GRUB call into
firmware's function, you can write a verifier to do that and register your
verifier with grub_verifier_register().

To be clear, I am not experienced for EFI and grub, I try my best to
give info :)

Me too :)

Best Regards,
Zhang Boyang

As explained above, we don't want to introduce any new verifier in
grub, it's about we want to verify image in U-boot EFT rather than in
grub.  So this is why I wrote this patch to dimiss the failure in grub
and pass image info to U-boot EFI service.  (and sorry my commit log
introduced confusion).



Grub-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]