Hi Daniel,
Secureboot worked fine with the change(GRUB_FILE_TYPE_LINUX_KERNEL ->
GRUB_FILE_TYPE_NONE) you suggested.
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: 0
disk/efi/efidisk.c:593: reading 0x40 sectors at the sector 0xcc40 from hd0
loader/arm64/linux.c:61: UEFI stub kernel:
loader/arm64/linux.c:62: PE/COFF header @ 00000040
loader/arm64/linux.c:316: kernel file size: 34054136
loader/arm64/linux.c:318: kernel numpages: 8314
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
....
loader/efi/fdt.c:63: allocating 1155 bytes for fdt
loader/arm64/linux.c:89: Initrd @ 0xf6e20000-0xf6fffa00
loader/efi/fdt.c:97: Installed/updated FDT configuration table @ 0xf71d0000
Loading driver at 0x000F4D10000 EntryPoint=0x000F650EDD8
Loading driver at 0x000F4D10000 EntryPoint=0x000F650EDD8
loader/arm64/linux.c:144: linux command line: 'BOOT_IMAGE=/Image acpi=force
console=ttyAMA0,115200 ip=dhcp
root=PARTUUID=9c53a91b-e182-4ff1-aeac-6ee2c432ae94 rootwait verbose debug'
loader/arm64/linux.c:159: starting image 0xfca9a798
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable
EFI stub: UEFI Secure Boot is enabled.
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
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.
What can we infer from the change you suggested and that it worked? Do we need
to make certain changes in our platform?
Thanks,
Sayanta
>-----Original Message-----
>From: Daniel Kiper <dki...@net-space.pl>
>Sent: Thursday, July 8, 2021 6:58 PM
>To: Sayanta Pattanayak <sayanta.pattana...@arm.com>
>Cc: grub-devel@gnu.org; nd <n...@arm.com>; javi...@redhat.com;
>x...@ubuntu.com; pjo...@redhat.com; l...@nuviainc.com
>Subject: Re: UEFI Secureboot not succeeding with Grub 2.06 and later version
>
>On Thu, Jul 08, 2021 at 07:04:46AM +0000, Sayanta Pattanayak wrote:
>> Hi Daniel,
>>
>> Thanks for your reply and hope you had a great vacation.
>
>Yeah, I had nice time.
>
>> We use Upstream 2.06 tagged version. Mentioning below the Build
>Commands and Console Output.
>
>Thanks! Please look below.
>
>[...]
>
>> kern/disk.c:196: Opening `hd0,gpt2'...
>> disk/efi/efidisk.c:482: opening hd0
>> disk/efi/efidisk.c:511: m = 0xfe6e8dc0, last block = 6efff, block size =
>> 200, io
>align = 0
>> 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
>
>If you use LoadImage() interface this should not happen.
>
>I think the following code in grub-core/loader/arm64/linux.c is a culprit:
>
> 285 static grub_err_t
> 286 grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
> 287 int argc, char *argv[])
> 288 {
> 289 grub_file_t file = 0;
> 290 struct linux_arch_kernel_header lh;
> 291 grub_err_t err;
> 292
> 293 grub_dl_ref (my_mod);
> 294
> 295 if (argc == 0)
> 296 {
> 297 grub_error (GRUB_ERR_BAD_ARGUMENT, N_("filename expected"));
> 298 goto fail;
> 299 }
> 300
> 301 file = grub_file_open (argv[0], GRUB_FILE_TYPE_LINUX_KERNEL);
>This ---------------------------------> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>You can do test and replace GRUB_FILE_TYPE_LINUX_KERNEL with
>GRUB_FILE_TYPE_NONE.
>
>Daniel
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
