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

[Zhang Boyang <zhangboyang.id@gmail.com>]

Hi,

On 2022/12/22 20:22, Leo Yan wrote:
> Hi Boyang,
> 
> On Thu, Dec 22, 2022 at 07:25:13PM +0800, Zhang Boyang wrote:
>> Hi,
>>
>> 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. (https://github.com/rhboot/shim )

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).
> 
> Thanks,
> Leo
> 
> [1] https://github.com/u-boot/u-boot/blob/master/lib/efi_loader/efi_boottime.c#L2021
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel