* Re: [PATCH] efi/libstub/arm64: avoid image_base value from efi_loaded_image
@ 2020-03-31 7:56 ` Ard Biesheuvel
0 siblings, 0 replies; 26+ messages in thread
From: Ard Biesheuvel @ 2020-03-31 7:56 UTC (permalink / raw)
To: Michael Kelley, lersek; +Cc: linux-efi, Boqun Feng, Leif Lindholm, Linux ARM
On Mon, 30 Mar 2020 at 20:24, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Mon, 30 Mar 2020 at 20:12, Michael Kelley <mikelley@microsoft.com> wrote:
> >
> > 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.
> >
>
> 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?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: [PATCH] efi/libstub/arm64: avoid image_base value from efi_loaded_image
2020-03-31 7:56 ` Ard Biesheuvel
@ 2020-03-31 13:37 ` Michael Kelley
-1 siblings, 0 replies; 26+ messages in thread
From: Michael Kelley @ 2020-03-31 13:37 UTC (permalink / raw)
To: Ard Biesheuvel, lersek; +Cc: Leif Lindholm, Linux ARM, linux-efi, Boqun Feng
From: Ard Biesheuvel <ardb@kernel.org> Sent: Tuesday, March 31, 2020 12:56 AM
>
> On Mon, 30 Mar 2020 at 20:24, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Mon, 30 Mar 2020 at 20:12, Michael Kelley <mikelley@microsoft.com> wrote:
> > >
> > > 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.
> > >
> >
> > 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?
Or there could be something weird about my Hyper-V VM. I have a
couple of ARM64 bare metal machines, but they are in the office
with no remote access, and we're on the work-from-home plan for
now. But I may be able to get into the office later this week and
try it. I'd like to rule out anything related to Hyper-V, and will
update this thread if I can.
Michael
^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: [PATCH] efi/libstub/arm64: avoid image_base value from efi_loaded_image
@ 2020-03-31 13:37 ` Michael Kelley
0 siblings, 0 replies; 26+ messages in thread
From: Michael Kelley @ 2020-03-31 13:37 UTC (permalink / raw)
To: Ard Biesheuvel, lersek; +Cc: linux-efi, Boqun Feng, Leif Lindholm, Linux ARM
From: Ard Biesheuvel <ardb@kernel.org> Sent: Tuesday, March 31, 2020 12:56 AM
>
> On Mon, 30 Mar 2020 at 20:24, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Mon, 30 Mar 2020 at 20:12, Michael Kelley <mikelley@microsoft.com> wrote:
> > >
> > > 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.
> > >
> >
> > 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?
Or there could be something weird about my Hyper-V VM. I have a
couple of ARM64 bare metal machines, but they are in the office
with no remote access, and we're on the work-from-home plan for
now. But I may be able to get into the office later this week and
try it. I'd like to rule out anything related to Hyper-V, and will
update this thread if I can.
Michael
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: [PATCH] efi/libstub/arm64: avoid image_base value from efi_loaded_image
2020-03-31 13:37 ` Michael Kelley
@ 2020-04-06 17:13 ` Michael Kelley
-1 siblings, 0 replies; 26+ messages in thread
From: Michael Kelley @ 2020-04-06 17:13 UTC (permalink / raw)
To: Ard Biesheuvel, lersek; +Cc: Leif Lindholm, Linux ARM, linux-efi, Boqun Feng
From: Michael Kelley Sent: Tuesday, March 31, 2020 6:38 AM
>
> From: Ard Biesheuvel <ardb@kernel.org> Sent: Tuesday, March 31, 2020 12:56 AM
> >
> > On Mon, 30 Mar 2020 at 20:24, Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Mon, 30 Mar 2020 at 20:12, Michael Kelley <mikelley@microsoft.com> wrote:
> > > >
> > > > 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.
> > > >
> > >
> > > 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?
>
> Or there could be something weird about my Hyper-V VM. I have a
> couple of ARM64 bare metal machines, but they are in the office
> with no remote access, and we're on the work-from-home plan for
> now. But I may be able to get into the office later this week and
> try it. I'd like to rule out anything related to Hyper-V, and will
> update this thread if I can.
>
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.
Michael
^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: [PATCH] efi/libstub/arm64: avoid image_base value from efi_loaded_image
@ 2020-04-06 17:13 ` Michael Kelley
0 siblings, 0 replies; 26+ messages in thread
From: Michael Kelley @ 2020-04-06 17:13 UTC (permalink / raw)
To: Ard Biesheuvel, lersek; +Cc: linux-efi, Boqun Feng, Leif Lindholm, Linux ARM
From: Michael Kelley Sent: Tuesday, March 31, 2020 6:38 AM
>
> From: Ard Biesheuvel <ardb@kernel.org> Sent: Tuesday, March 31, 2020 12:56 AM
> >
> > On Mon, 30 Mar 2020 at 20:24, Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Mon, 30 Mar 2020 at 20:12, Michael Kelley <mikelley@microsoft.com> wrote:
> > > >
> > > > 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.
> > > >
> > >
> > > 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?
>
> Or there could be something weird about my Hyper-V VM. I have a
> couple of ARM64 bare metal machines, but they are in the office
> with no remote access, and we're on the work-from-home plan for
> now. But I may be able to get into the office later this week and
> try it. I'd like to rule out anything related to Hyper-V, and will
> update this thread if I can.
>
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.
Michael
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] efi/libstub/arm64: avoid image_base value from efi_loaded_image
2020-04-06 17:13 ` Michael Kelley
@ 2020-04-07 8:07 ` Ard Biesheuvel
-1 siblings, 0 replies; 26+ messages in thread
From: Ard Biesheuvel @ 2020-04-07 8:07 UTC (permalink / raw)
To: Michael Kelley; +Cc: lersek, Leif Lindholm, Linux ARM, linux-efi, Boqun Feng
On Mon, 6 Apr 2020 at 19:13, Michael Kelley <mikelley@microsoft.com> wrote:
>
> From: Michael Kelley Sent: Tuesday, March 31, 2020 6:38 AM
> >
> > From: Ard Biesheuvel <ardb@kernel.org> Sent: Tuesday, March 31, 2020 12:56 AM
> > >
> > > On Mon, 30 Mar 2020 at 20:24, Ard Biesheuvel <ardb@kernel.org> wrote:
> > > >
> > > > On Mon, 30 Mar 2020 at 20:12, Michael Kelley <mikelley@microsoft.com> wrote:
> > > > >
> > > > > 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.
> > > > >
> > > >
> > > > 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?
> >
> > Or there could be something weird about my Hyper-V VM. I have a
> > couple of ARM64 bare metal machines, but they are in the office
> > with no remote access, and we're on the work-from-home plan for
> > now. But I may be able to get into the office later this week and
> > try it. I'd like to rule out anything related to Hyper-V, and will
> > update this thread if I can.
> >
>
> 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.
>
Thanks Michael. I'll mention this in the bugzilla entry.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] efi/libstub/arm64: avoid image_base value from efi_loaded_image
@ 2020-04-07 8:07 ` Ard Biesheuvel
0 siblings, 0 replies; 26+ messages in thread
From: Ard Biesheuvel @ 2020-04-07 8:07 UTC (permalink / raw)
To: Michael Kelley; +Cc: linux-efi, Boqun Feng, Leif Lindholm, lersek, Linux ARM
On Mon, 6 Apr 2020 at 19:13, Michael Kelley <mikelley@microsoft.com> wrote:
>
> From: Michael Kelley Sent: Tuesday, March 31, 2020 6:38 AM
> >
> > From: Ard Biesheuvel <ardb@kernel.org> Sent: Tuesday, March 31, 2020 12:56 AM
> > >
> > > On Mon, 30 Mar 2020 at 20:24, Ard Biesheuvel <ardb@kernel.org> wrote:
> > > >
> > > > On Mon, 30 Mar 2020 at 20:12, Michael Kelley <mikelley@microsoft.com> wrote:
> > > > >
> > > > > 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.
> > > > >
> > > >
> > > > 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?
> >
> > Or there could be something weird about my Hyper-V VM. I have a
> > couple of ARM64 bare metal machines, but they are in the office
> > with no remote access, and we're on the work-from-home plan for
> > now. But I may be able to get into the office later this week and
> > try it. I'd like to rule out anything related to Hyper-V, and will
> > update this thread if I can.
> >
>
> 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.
>
Thanks Michael. I'll mention this in the bugzilla entry.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] efi/libstub/arm64: avoid image_base value from efi_loaded_image
2020-03-31 7:56 ` Ard Biesheuvel
@ 2020-03-31 19:20 ` Laszlo Ersek
-1 siblings, 0 replies; 26+ messages in thread
From: Laszlo Ersek @ 2020-03-31 19:20 UTC (permalink / raw)
To: Ard Biesheuvel, Michael Kelley
Cc: Leif Lindholm, Linux ARM, linux-efi, Boqun Feng
On 03/31/20 09:56, Ard Biesheuvel wrote:
> On Mon, 30 Mar 2020 at 20:24, Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> On Mon, 30 Mar 2020 at 20:12, Michael Kelley <mikelley@microsoft.com> wrote:
>>>
>>> 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.
>>>
>>
>> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] efi/libstub/arm64: avoid image_base value from efi_loaded_image
@ 2020-03-31 19:20 ` Laszlo Ersek
0 siblings, 0 replies; 26+ messages in thread
From: Laszlo Ersek @ 2020-03-31 19:20 UTC (permalink / raw)
To: Ard Biesheuvel, Michael Kelley
Cc: linux-efi, Boqun Feng, Leif Lindholm, Linux ARM
On 03/31/20 09:56, Ard Biesheuvel wrote:
> On Mon, 30 Mar 2020 at 20:24, Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> On Mon, 30 Mar 2020 at 20:12, Michael Kelley <mikelley@microsoft.com> wrote:
>>>
>>> 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.
>>>
>>
>> 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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] efi/libstub/arm64: avoid image_base value from efi_loaded_image
2020-03-31 19:20 ` Laszlo Ersek
@ 2020-04-01 8:24 ` Ard Biesheuvel
-1 siblings, 0 replies; 26+ messages in thread
From: Ard Biesheuvel @ 2020-04-01 8:24 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Michael Kelley, Leif Lindholm, Linux ARM, linux-efi, Boqun Feng
On Tue, 31 Mar 2020 at 21:20, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 03/31/20 09:56, Ard Biesheuvel wrote:
> > On Mon, 30 Mar 2020 at 20:24, Ard Biesheuvel <ardb@kernel.org> wrote:
> >>
> >> On Mon, 30 Mar 2020 at 20:12, Michael Kelley <mikelley@microsoft.com> wrote:
> >>>
> >>> 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.
> >>>
> >>
> >> 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.
>
https://bugzilla.redhat.com/show_bug.cgi?id=1819624
Thanks.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] efi/libstub/arm64: avoid image_base value from efi_loaded_image
@ 2020-04-01 8:24 ` Ard Biesheuvel
0 siblings, 0 replies; 26+ messages in thread
From: Ard Biesheuvel @ 2020-04-01 8:24 UTC (permalink / raw)
To: Laszlo Ersek
Cc: linux-efi, Boqun Feng, Leif Lindholm, Linux ARM, Michael Kelley
On Tue, 31 Mar 2020 at 21:20, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 03/31/20 09:56, Ard Biesheuvel wrote:
> > On Mon, 30 Mar 2020 at 20:24, Ard Biesheuvel <ardb@kernel.org> wrote:
> >>
> >> On Mon, 30 Mar 2020 at 20:12, Michael Kelley <mikelley@microsoft.com> wrote:
> >>>
> >>> 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.
> >>>
> >>
> >> 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.
>
https://bugzilla.redhat.com/show_bug.cgi?id=1819624
Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 26+ messages in thread