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

From: Michael Kelley <mikelley@microsoft.com>
To: Ard Biesheuvel <ardb@kernel.org>, Leif Lindholm <leif@nuviainc.com>
Cc: Boqun Feng <Boqun.Feng@microsoft.com>,
	linux-efi <linux-efi@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH] efi/libstub/arm64: avoid image_base value from efi_loaded_image
Date: Mon, 30 Mar 2020 18:12:37 +0000	[thread overview]
Message-ID: <DM5PR2101MB104760D03E632DD4DBE99AE1D7CB0@DM5PR2101MB1047.namprd21.prod.outlook.com> (raw)
In-Reply-To: <CAMj1kXEf5rT1pmDNQoOd5Tx9xQ=fUMT0xo4JXZNfz=VDY9268Q@mail.gmail.com>

From: Ard Biesheuvel <ardb@kernel.org>  Sent: Monday, March 30, 2020 12:51 AM
> 
> On Mon, 30 Mar 2020 at 09:50, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Mon, 30 Mar 2020 at 09:47, Leif Lindholm <leif@nuviainc.com> 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.

Michael
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel