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
Summary: | FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jeremy Linton <jeremy.linton> | ||||||
Component: | grub2 | Assignee: | Javier Martinez Canillas <fmartine> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 34 | CC: | fmartine, lkundrak, lnie, pbrobinson, pjones, pwhalen | ||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||
Target Release: | --- | ||||||||
Hardware: | aarch64 | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | grub2-2.04-14.fc32 | Doc Type: | If docs needed, set a value | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2021-06-11 00:28:07 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 245418 | ||||||||
Attachments: |
|
Description
Jeremy Linton
2020-04-17 22:20:49 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. 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. Created attachment 1681173 [details]
[PATCH] efi: Set image base address before jumping to the PE/COFF entry point
Created attachment 1681174 [details]
grub2-efi-aa64-2.04-14.fc33.aarch64.rpm
Changing the Version to Rawhide since the issue happens since v5.7-rc1 (already in Rawhide) but F32 still has v5.6. FEDORA-2020-e38f21d14d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e38f21d14d 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. 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. 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. (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 ? >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... This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34. This should had been fixed by now, if the issue persists feel free to re-open the bug. |