Re: [edk2-devel] ArmVirtPkg: non-executable EFI_LOADER_DATA breaks GRUB on Ubuntu 22.04

["Michael D Kinney" <michael.d.kinney@intel.com>]

A general approach to this type of issues is to enable the new feature by default
and optionally provide a setup option to disable the new feature.

If there is a way to detect the failure case and fail gracefully back to the 
boot manager with an error message that indicates the type of issue and also
indicates if there is a setup option to disable a feature to allow that OS
to boot, then the user can choose to opt-in to disabling the feature.

Can also consider a warning message when a system is in a defeatured state
so the user knows that every time they boot so they can re-enable if they
only needed to disable for a short period of time.

Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Oliver
> Smith-Denny
> Sent: Thursday, July 13, 2023 11:23 AM
> To: devel@edk2.groups.io; pedro.falcato@gmail.com; Ard Biesheuvel
> <ardb@kernel.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>; osy@turing.llc; Leif Lindholm
> <quic_llindhol@quicinc.com>; dann frazier <dann.frazier@canonical.com>
> Subject: Re: [edk2-devel] ArmVirtPkg: non-executable EFI_LOADER_DATA
> breaks GRUB on Ubuntu 22.04
> 
> On 7/13/2023 10:41 AM, Pedro Falcato wrote:
> > On Thu, Jul 13, 2023 at 6:20 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >>
> >> On Thu, 13 Jul 2023 at 18:57, Pedro Falcato <pedro.falcato@gmail.com>
> wrote:
> >>>
> >>> On Tue, Jul 11, 2023 at 7:58 AM Gerd Hoffmann <kraxel@redhat.com>
> wrote:
> >>>>
> >>>> On Mon, Jul 10, 2023 at 04:58:15PM +0100, Pedro Falcato wrote:
> >>>>> On Mon, Jul 10, 2023 at 2:28 PM <osy@turing.llc> wrote:
> >>>>>>
> >>>>>> I have an existing install of Ubuntu 22.04 on a QEMU virtual
> machine which I've decided to update the UEFI firmware. After doing so,
> GRUB no longer boots ("Synchronous Exception" message seen). After a git
> bisect session, I found the problematic
> 2997ae38739756ecba9b0de19e86032ebc689ef9. The comment says GRUB should
> have been fixed in 2017, but for one reason or another, my VM which was
> built in 2022 still had the issue. Regardless, I don't think it's a good
> idea to break GRUB, even if it's fixed in 2017. In the very least, a
> better error message would be preferable to crashing with an
> "Synchronous Exception." Googling this error message shows that other
> people may be hitting this issue as well but the vague error symptom
> means its impossible to know if it's the same issue or not.
> >>>>>
> >>>>> +CC Some of the folks involved in the original discussion
> >>>>>
> >>>>> In the original thread, people discussed some alternative behavior
> to
> >>>>> just crashing on a NX fault. Is this still an alternative?
> >>>>
> >>>> The idea is: Improve page fault handler to (a) print a big'n'fat
> >>>> warning, and (b) loosening up memory permissions for the faulting
> >>>> page address.
> >>>>
> >>>> No patch for that emerged (yet?).
> >>>
> >>> Ack. I can work on that.
> >>>
> >>>>> I'm kind of thinking this should be addressed by distros
> anyway....
> >>>>> How is $CURRENT_YEAR Ubuntu still shipping bad GRUBs? I know the
> >>>>> situation around GRUB and distro patching is complicated but...
> >>>>> Do we have any idea of how many distros/GRUBs are affected by
> this?
> >>>>
> >>>> Too many :(
> >>>
> >>> Ugh, even the latest releases?
> >>>
> >>>>> Personally, I would like to avoid loosening up memory permissions.
> >>>>
> >>>> Well, you can't have both.  You have to pick between strict nx
> handling
> >>>> and grub bug compatibility ...
> >>>
> >>> Yes. IMO it should be ok to add a hack around NX handling if there's
> a
> >>> solid plan for dealing with this from the distros' side (and phasing
> >>> this out). And I'm assuming upstream GRUB has this fixed.
> >>> This whole situation is kind of messy as firmware people add new
> >>> restrictions that weren't really there in the first place.
> >>>
> >>> Also, what's the situation on this for x86? I assume it's a lot
> worse there?
> >>>
> >>
> >> To be honest, I have little sympathy for the gigantic mess that the
> >> distros have created for themselves with GRUB, shim, etc. Mainline
> >> GRUB works fine with mainline EDK2, and secure boot in a arm64 VM is
> >> rather pointless, given that the [emulated] NOR flash is writable by
> >> the guest OS. The breakage is in the downstream GRUB changes that
> make
> >> it interoperate with shim, and its hacked up PE loader.
> >>
> >> If we are going to accommodate every broken GRUB build that the
> >> distros ever released, we won't be able to make any progress on this
> >> front. I understand that the distros need to support their existing
> >> user bases, so I am willing to consider facilities that make it
> easier
> >> to create builds that work around such issues.
> >>
> >> However, just turning off NX support is not one of the options.
> >> Upstream is not what the distros are shipping, this applies to GRUB
> >> and shim as well as EDK2: so if their downstream GRUB breaks EDK2,
> >> they can fix it in their EDK2 builds, either by carrying a code
> >> change, or by enabling an upstream build flag that is off by default.
> >
> > I understand your sentiment, but I don't see how this can work. Let's
> > say Fedora has a fixed GRUB (I have no idea if this is the case), so
> > they have a fully-NX'd edk2. Then someone tries to boot Ubuntu 22.04 -
> > it crashes because Ubuntu's GRUB is borked; what now? I don't know if
> > this case is super prevalent in virtualization, but it's definitely a
> > problem (and it seems to have happened to osy here?).
> >
> > I agree that turning off NX sucks, but so does not being able to boot
> > into distros as recent as Ubuntu 22.04. It might be that a single
> > Sleep(10); +  a nice loud error message gets the idea across? maybe
> > over a stable tag or so, then we remove the hack and add full-NX. What
> > do you think?
> >
> 
> I agree with Ard here. If other software is buggy and outdated, our
> general approach should be fix your outdated and buggy software,
> especially when there are security and safety implications to bending
> backwards for broken code.
> 
> A downstream platform may well need to support buggy OSes, etc. for the
> lifespan of the device, but upstream edk2 is not the right place to add
> hacks for buggy external software. edk2 is our opportunity to do the
> right thing and help encourage the community to the right place.
> 
> When distros have the maintenance burden of working with downstream
> platforms to support their lack of updating grub etc., they may decide
> it is worthwhile to actually update grub...
> 
> Thanks,
> Oliver
> 
> 
> 
>