1825411 – FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value

Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1825411 - FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value

Summary: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value

Keywords:
Status:	CLOSED CURRENTRELEASE
Alias:	None
Product:	Fedora
Classification:	Fedora
Component:	grub2
Sub Component:
Version:	34
Hardware:	aarch64
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	---
Assignee:	Javier Martinez Canillas
QA Contact:	Fedora Extras Quality Assurance
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	ARMTracker
TreeView+	depends on / blocked

Reported:	2020-04-17 22:20 UTC by Jeremy Linton
Modified:	2021-06-11 00:28 UTC (History)
CC List:	6 users (show)
Fixed In Version:	grub2-2.04-14.fc32
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2021-06-11 00:28:07 UTC
Type:	Bug
Embargoed:
Dependent Products:

Attachments	(Terms of Use)
[PATCH] efi: Set image base address before jumping to the PE/COFF entry point (2.28 KB, patch) 2020-04-23 15:37 UTC, Javier Martinez Canillas	no flags	Details \| Diff
grub2-efi-aa64-2.04-14.fc33.aarch64.rpm (508.85 KB, application/x-rpm) 2020-04-23 15:41 UTC, Javier Martinez Canillas	no flags	Details
View All

Description Jeremy Linton 2020-04-17 22:20:49 UTC

Description of problem: Linux 5.7rc1 has a new commit c2136dceba9a3 "efi/libstub/arm: Avoid image_base value from efi_loaded_image" which is verifying the efi_loaded_images structure's image base field.

30 seconds of investigation make it appear that the comment in the bug about this being caused by older grub builds is what is happening on fedora. I see this on two different aarch64/edk2 machines (one is the rpi4/pftf build, which at first pass looks correct).

Version-Release number of selected component (if applicable): F32+5.7rc1

How reproducible: 100% of the time during boot.

Steps to Reproduce:
1. Install a f32 + a bleeding edge kernel
2. Boot machine, pay attention to messages from the kernel stub being displayed on the serial port.
3.

Actual results:
EFI stub: Booting Linux Kernel...
EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...

Expected results:
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...

Additional info:

Comment 1 Javier Martinez Canillas 2020-04-22 11:48:39 UTC

This is easily reproducible with edk2-ovmf and qemu-system-aarch64.

With the latest GRUB in Fedora Rawhide I get the output mentioned in the bug description: 

EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...

and the issue is not present with upstream GRUB:

EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...

so one of the patches in the Fedora grub2 package seems to be the culprit.

Comment 2 Javier Martinez Canillas 2020-04-23 15:35:14 UTC

I found the issue. Upstream GRUB uses the EFI LoadImage() and StartImage() services to boot the Linux kernel, but we have a custom EFI loader to support Secure Boot that instead uses the EFI handover protocol (for x86) or jumping directly to the PE/COFF entry point (for aarch64).
    
This is done to allow the bootloader to verify the images using the shim lock protocol to avoid booting untrusted binaries. So since LoadImage() is not used and the Loaded Image base address is set by the firmware when that service is called, GRUB should set the base address.

I'll attach a patch fixing this and also a scratch build for testing.

Comment 3 Javier Martinez Canillas 2020-04-23 15:37:58 UTC

Created attachment 1681173 [details]
[PATCH] efi: Set image base address before jumping to the PE/COFF entry point

Comment 4 Javier Martinez Canillas 2020-04-23 15:41:13 UTC

Created attachment 1681174 [details]
grub2-efi-aa64-2.04-14.fc33.aarch64.rpm

Comment 5 Javier Martinez Canillas 2020-04-23 19:43:13 UTC

Changing the Version to Rawhide since the issue happens since v5.7-rc1 (already in Rawhide) but F32 still has v5.6.

Comment 6 Fedora Update System 2020-04-24 15:44:22 UTC

FEDORA-2020-e38f21d14d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e38f21d14d

Comment 7 Fedora Update System 2020-04-25 12:21:15 UTC

FEDORA-2020-e38f21d14d has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-e38f21d14d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e38f21d14d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Fedora Update System 2020-04-28 02:31:20 UTC

FEDORA-2020-e38f21d14d has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 9 lnie 2020-11-05 01:36:31 UTC

See this bug again with hpe servers https://beaker.engineering.redhat.com/jobs/4704179,
others servers are fine:https://beaker.engineering.redhat.com/jobs/4704271.
I checked f32 and f33 on the failed hpe servers, both work well.

Comment 10 Javier Martinez Canillas 2020-12-30 14:01:22 UTC

(In reply to lnie from comment #9)
> See this bug again with hpe servers
> https://beaker.engineering.redhat.com/jobs/4704179,
> others servers are fine:https://beaker.engineering.redhat.com/jobs/4704271.

Unfortunately these logs have been already removed. I'ts better to share the
relevant logs.

> I checked f32 and f33 on the failed hpe servers, both work well.

All Fedora branches since F32 have the relevant fix. Can you please share the
kernel version used in all cases to check if there was a change there ?

Comment 11 lnie 2020-12-31 04:27:05 UTC

>Unfortunately these logs have been already removed. I'ts better to share the relevant logs.

Sure, here is one rawhide job:
https://beaker.engineering.redhat.com/jobs/4937337

and here is one successful f33 job:
https://beaker.engineering.redhat.com/jobs/4937353

>All Fedora branches since F32 have the relevant fix. Can you please share the kernel version used in all cases to check if there was a change there ?

I've checked,the f33 job has kernel-5.9.16-200.fc33 installed,while rawhide has kernel-5.10.0-0.rc6.20201204git34816d20f173.92.fc34,
if I get kernel-5.10.4-200.fc33 from koji and install it to the f33 server and reboot it,the server will stuck as follows:
 
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...

Comment 12 Ben Cotton 2021-02-09 15:14:45 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Comment 13 Javier Martinez Canillas 2021-06-11 00:28:07 UTC

This should had been fixed by now, if the issue persists feel free to re-open the bug.

Note You need to log in before you can comment on or make changes to this bug.