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.