Hi Javier,
I tried with your suggested change, but observing Exception as following -
disk/efi/efidisk.c:531: opening hd0 succeeded
partmap/gpt.c:93: Read a valid GPT header
partmap/gpt.c:115: GPT entry 0: start=2048, length=40959
partmap/gpt.c:115: GPT entry 1: start=43008, length=409599
kern/fs.c:56: Detecting ext2...
kern/verifiers.c:88: file: /Image type: 3
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0xcc40 from hd0
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0xcc80 from hd0
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0xccc0 from hd0
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0xcd00 from hd0
.....
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0x1dc00 from hd0
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0x1dc40 from hd0
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0x1dc80 from hd0
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0x1dcc0 from hd0
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0x1dd00 from hd0
Synchronous Exception at 0x00000000F92699DC
Synchronous Exception at 0x00000000F92699DC
PC 0x0000F92699DC
PC 0x0000F92699A8
PC 0x0000F92709B8
PC 0x0000F926D2BC
PC 0x0081FFF64644
PC 0x0081FFF87B84
PC 0x0081FFF86788
PC 0x0081FFF87614
PC 0x0081FFF86788
PC 0x0081FFF87D00
PC 0x0081FFF87D58
PC 0x0081FFF7E334
PC 0x0081FFF7E04C
PC 0x0081FFF7A398
PC 0x0081FFF7A7B4
PC 0x0081FFF7A890
PC 0x0000F926DE84
PC 0x0000FE955A78 (0x0000FE94E000+0x00007A78) [ 1] DxeCore.dll
PC 0x0000FE74EF58 (0x0000FE747000+0x00007F58) [ 2] BdsDxe.dll
PC 0x0000FE7514A8 (0x0000FE747000+0x0000A4A8) [ 2] BdsDxe.dll
PC 0x0000FE95922C (0x0000FE94E000+0x0000B22C) [ 3] DxeCore.dll
Another doubt, should the Image be detected as "UEFI stub kernel", as happened
with experimental suggestion by Daniel?
One minor addition in your patch, added below.
Thanks
>-----Original Message-----
>From: Javier Martinez Canillas <javi...@redhat.com>
>Sent: Thursday, July 15, 2021 4:58 PM
>To: Sayanta Pattanayak <sayanta.pattana...@arm.com>; Daniel Kiper
><dki...@net-space.pl>
>Cc: grub-devel@gnu.org; nd <n...@arm.com>; x...@ubuntu.com;
>pjo...@redhat.com; l...@nuviainc.com
>Subject: Re: UEFI Secureboot not succeeding with Grub 2.06 and later version
>
>Hello Sayanta,
>
>On 7/15/21 7:26 AM, Sayanta Pattanayak wrote:
>
>[snip]
>
>>>> We understand LoadImage() interface is used in our platform, but if
>>>> the error scenario is not expected with LoadImage() interface then
>>>> we need further investigation. We are trying to look into it.
>>>>
>
>I agree with the assessment made by others that validating using the UEFI
>firmware should be a supported configuration if the image is built with the --
>disable-shim-lock option.
>
>>>> What can we infer from the change you suggested and that it worked?
>>>> Do we need to make certain changes in our platform?
>>>
>>> The change which I suggested was just a check for my theory. It is not real
>fix.
>>> We have to fix this issue in the GRUB in a different way. This is not your
>fault.
>>> When we have a fix we will ask you for some tests.
>>
>> Thanks for the information. Sure, will look forward for the change and
>further experiments to perform.
>>
>
>Could you please try the following patch? I've not tested it yet but I think
>that
>should make GRUB to support your use case.
>
>From 37157118e237f216866e185e53f8f7d6c9233407 Mon Sep 17 00:00:00 2001
>From: Javier Martinez Canillas <javi...@redhat.com>
>Date: Thu, 15 Jul 2021 13:08:11 +0200
>Subject: [RFC PATCH] kern/efi/sb: Allow validation to be done by the UEFI
>firmware
>
>The shim_lock protocol is used to delegate that PE32+ binaries have been
>signed with a trusted key. This is done because GRUB currently lacks the
>ability to do the validation itself.
>
>But in certain configurations a user may not want to use shim for this, and
>either delegate on a different verifier (i.e: pgp) or just leave it to the UEFI
>firmware. The latter can be done if both GRUB and the Linux kernel have
>been signed by a key trusted by the UEFI firmware.
>
>There's an grub-mkimage --disable-shim-lock option that could be used to
>avoid using he shim_lock protocol and rely on another verifier, but that will
>not work for the latter case. Since the lockdown verifier defers it to another
>verifier but no verifier validates the Linux kernel images.
>
>To workaround that, let's make the shim_lock verifier always validate a kernel
>file type if the --disable-shim-lock option has been enabled.
>
>Reported-by: Sayanta Pattanayak <sayanta.pattana...@arm.com>
>Signed-off-by: Javier Martinez Canillas <javi...@redhat.com>
>---
> grub-core/kern/efi/sb.c | 21 ++++++++++-----------
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
>diff --git a/grub-core/kern/efi/sb.c b/grub-core/kern/efi/sb.c index
>c52ec6226a6..51af1a21546 100644
>--- a/grub-core/kern/efi/sb.c
>+++ b/grub-core/kern/efi/sb.c
>@@ -143,8 +143,17 @@ shim_lock_verifier_write (void *context
>__attribute__ ((unused)), void *buf, gru {
+ struct grub_module_header *header;
> grub_efi_shim_lock_protocol_t *sl = grub_efi_locate_protocol
>(&shim_lock_guid, 0);
>
>+ /* shim_lock is missing, check if GRUB image is built with
>+ --disable-shim-lock. */
> if (!sl)
>- return grub_error (GRUB_ERR_ACCESS_DENIED, N_("shim_lock protocol
>not found"));
>+ {
>+ FOR_MODULES (header)
>+ {
>+ if (header->type == OBJ_TYPE_DISABLE_SHIM_LOCK)
>+ return GRUB_ERR_NONE;
>+
>+ return grub_error (GRUB_ERR_ACCESS_DENIED, N_("shim_lock
>protocol not found"));
>+ }
>+ }
>
> if (sl->verify (buf, size) != GRUB_EFI_SUCCESS)
> return grub_error (GRUB_ERR_BAD_SIGNATURE, N_("bad shim
>signature")); @@ -166,16 +175,6 @@ grub_shim_lock_verifier_setup (void)
> grub_efi_shim_lock_protocol_t *sl =
> grub_efi_locate_protocol (&shim_lock_guid, 0);
>
>- /* shim_lock is missing, check if GRUB image is built with
>--disable-shim-lock.
>*/
>- if (!sl)
>- {
>- FOR_MODULES (header)
>- {
>- if (header->type == OBJ_TYPE_DISABLE_SHIM_LOCK)
>- return;
>- }
>- }
>-
> /* Secure Boot is off. Do not load shim_lock. */
> if (grub_efi_get_secureboot () !=
>GRUB_EFI_SECUREBOOT_MODE_ENABLED)
> return;
>--
>2.31.1
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
