On 03/31/20 09:56, Ard Biesheuvel wrote: > On Mon, 30 Mar 2020 at 20:24, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: >> >> On Mon, 30 Mar 2020 at 20:12, Michael Kelley <mikelley@xxxxxxxxxxxxx> wrote: >>> >>> From: Ard Biesheuvel <ardb@xxxxxxxxxx> Sent: Monday, March 30, 2020 12:51 AM >>>> >>>> On Mon, 30 Mar 2020 at 09:50, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: >>>>> >>>>> On Mon, 30 Mar 2020 at 09:47, Leif Lindholm <leif@xxxxxxxxxxxx> wrote: >>>>>> >>>>>> On Sat, Mar 28, 2020 at 21:58:09 +0100, Ard Biesheuvel wrote: >>>>>>> Commit 9f9223778ef3 ("efi/libstub/arm: Make efi_entry() an ordinary >>>>>>> PE/COFF entrypoint") did some code refactoring to get rid of the >>>>>>> EFI entry point assembler code, and in the process, it got rid of the >>>>>>> assignment of image_addr to the value of _text. Instead, it switched >>>>>>> to using the image_base field of the efi_loaded_image struct provided >>>>>>> by UEFI, which should contain the same value. >>>>>>> >>>>>>> However, Michael reports that this is not the case: older GRUB builds >>>>>>> corrupt this value in some way, and since we can easily switch back to >>>>>>> referring to _text to discover this value, let's simply do that. >>>>>> >>>>>> It is not clear to me how "older GRUB builds" would differ here. >>>>>> I think more investigation is needed before making that claim. >>>>>> My suspicion is that some (old) version of non-upstream, shim-enabled >>>>>> distro-specific build is playing a part. >>>>>> >>>>>> So, do we have the option for more detailed investigations, or can we >>>>>> vague the claim up to say "some GRUB builds seen in the wild, based >>>>>> on an upstream 2.02" or suchlike? >>>>>> >>>>> >>>>> I've queued a fix that prints a nastygram if the value deviates from >>>>> the expected one. Let's see if this triggers any reports. >>>> >>>> (/me looks at context) >>>> >>>> *This* is the fix that prints a nastygram. >>> >>> FWIW, I pulled the BOOTAA64.EFI and grubaa64.efi files from CentOS 7.6 >>> and CentOS 8.0 binary packages and tested both in my Hyper-V VM. >>> Using strings | grep '2\.' to get version info, the CentOS 7.6 grubaa64.efi >>> shows: >>> >>> User-Agent: GRUB 2.02~beta2 >>> >>> The CentOS 8.0 grubaa64.efi shows: >>> >>> User-Agent: GRUB 2.03 >>> >>> Both versions produce the FIRMWARE BUG warning when using Ard's >>> latest patch. I'll assume the equivalent RHEL versions are the same. >>> So we've got official distro releases that show the problem. >>> >>> As reported earlier, the BOOTAA64.EFI and grubaa64.efi from a >>> Debian release (not exactly sure which one) do not produce the >>> FIRMWARE BUG warning. The grubaa64.efi reports as 2.04-4. >>> >> >> Thanks a lot Michael, that is really helpful. > > I could not reproduce the issue with Debian Stretch's > 2.02~beta3-5+deb9u2, so it does appear to be RedHat's value add that > is to blame here. > > @Laszlo: TL;DR RedHat's GRUB for arm64 appears to clobber the > image_base field of the efi_loaded_image struct passed to the kernel. > Could you please recommend a way to report this? Yes. I seem to recall that you already have an account at <https://bugzilla.redhat.com/>. Please log in, then go to the following link: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208 In the "Component" field, please enter "grub2", then fill in Summary / Description / etc. Please be thorough, as if you wanted me to reproduce the issue :) After filing the bug, please send the BZ link to me (or add me to the bug's CC list), so I can ping some RH bootloader folks directly. Thanks! Laszlo