Re: [PATCH] efi/libstub/arm64: avoid image_base value from efi_loaded_image

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux