Bug 1819624
| Summary: | image_base member of EFI_LOADED_IMAGE is set incorrectly | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | ardb | ||||||||||
| Component: | grub2 | Assignee: | Javier Martinez Canillas <fmartine> | ||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> | ||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 8.3 | CC: | fmartine, jstodola, lersek, pbrobinson, perobins, pjanda | ||||||||||
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
||||||||||
| Target Release: | 8.0 | ||||||||||||
| Hardware: | aarch64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | grub2-2.02-82.el8 | Doc Type: | If docs needed, set a value | ||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | |||||||||||||
| : | 1921629 (view as bug list) | Environment: | |||||||||||
| Last Closed: | 2020-11-04 01:53:54 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: | 1921629 | ||||||||||||
| Attachments: |
|
||||||||||||
On Mon, 6 Apr 2020 at 19:13, Michael Kelley <mikelley> wrote: > ... > I have tried this scenario on bare metal running RHEL 7.4, and the > problem reproduces as described above. So this is *not* related to > running in a Hyper-V VM, which is what I wanted to make sure of. > https://lore.kernel.org/linux-efi/MW2PR2101MB1052F06F444705247419B2B3D7C20@MW2PR2101MB1052.namprd21.prod.outlook.com/ This is easily reproducible with edk2-ovmf and qemu-system-aarch64. With the latest GRUB in RHEL 8 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 RHEL 8 grub2 package seems to be the culprit. So the issue is that 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. 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 1681188 [details]
[PATCH] efi: Set image base address before jumping to the PE/COFF entry point
Created attachment 1681189 [details]
grub2-efi-aa64-2.02-82.el8.aarch64.rpm
Created attachment 1682401 [details]
vmlinuz
This can be reproduced using qemu-system-aarch64, edk2-aarch64 and an aarch64 v5.7-rc1 kernel.
I used the following command line:
qemu-system-aarch64 -machine virt -cpu cortex-a57 -m 1024 -display none -serial mon:stdio -pflash /usr/share/edk2/aarch64/QEMU_EFI-pflash.raw -drive format=vvfat,file=fat:test_dir
Where test_dir is a directory that contains the following files:
test_dir/
├── grubaa64.efi
├── grub.cfg
└── vmlinuz
Just booting the kernel is enough since the warning is printed by the kernel EFI stub. I'm attaching the grub.cfg and compiled vmlinuz to make testing easier.
Created attachment 1682405 [details]
grub.cfg
qa_ack , reproduced with provided kernel, checked, that err message is not printed when using attached grub2 build Note for QE specified err messages are printed at very begining of output and kernel tries to start - it panics eventually due missing root FS, but even in error state it works somehow... (In reply to Petr Janda from comment #9) > qa_ack , reproduced with provided kernel, checked, that err message is not > printed when using attached grub2 build > Thanks a lot. > Note for QE specified err messages are printed at very begining of output > and kernel tries to start - it panics eventually due missing root FS, but > even in error state it works somehow... Yes, I didn't provide an initramfs since as you mentioned the error is printed very early by the EFI stub, so I thought that it wouldn't be needed to reproduce the issue / verify the fix. I should had mentioned this. Reproduced on RHEL-8.2 GA with grub2-2.02-81.el8: 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... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x431f0af1] [ 0.000000] Linux version 5.7.0-rc2 (javier@minerva) (gcc version 9.2.1 20190827 (Red Hat Cross 9.2.1-1) (GCC), GNU ld version 2.32-4.fc31) #3 SMP PREEMPT Mon Apr 20 12:45:03 CEST 2020 The error is not present with grub2-2.02-84.el8: EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x431f0af1] [ 0.000000] Linux version 5.7.0-rc2 (javier@minerva) (gcc version 9.2.1 20190827 (Red Hat Cross 9.2.1-1) (GCC), GNU ld version 2.32-4.fc31) #3 SMP PREEMPT Mon Apr 20 12:45:03 CEST 2020 Moving to VERIFIED. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (grub2 bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4513 |
GRUB 2.03 for arm64, as shipped with CentOS 8.0, (and presumably, its RHEL counterpart) invokes the EFI stub in the kernel with the image_base field of the EFI_LOADED_IMAGE protocol installed onto the image handle set to an incorrect value. This was not noticed until recently, due to the fact that the EFI stub on arm64 is part of the kernel proper rather than part of the decompressor, and so it can simply obtain the same value using a place-relative reference to the _text symbol emitted by the linker. After Linux commit 9f9223778ef385e79dc67f5ee48ee4c1fb757f6b ("efi/libstub/arm: Make efi_entry() an ordinary PE/COFF entrypoint"), we received reports that some versions of GRUB could no longer boot the kernel, and we traced this back to Centos. We worked around the issue in c2136dceba9a329e997ccce3277d2084e21a8a04 ("efi/libstub/arm64: Avoid image_base value from efi_loaded_image") by switching back to using the _text symbol, but we left a console message in place that will warn about this condition in the following way EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value and the reporter of the issue has confirmed that this message gets emitted when booting using the same GRUB builds that were found to be affected before. To reproduce, it suffices to build a defconfig arm64 kernel from torvalds's master as of today, and boot it from GRUB. The message should be visible regardless of the 'quiet' kernel command line option.