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.falc...@gmail.com; Ard Biesheuvel > <a...@kernel.org> > Cc: Gerd Hoffmann <kra...@redhat.com>; o...@turing.llc; Leif Lindholm > <quic_llind...@quicinc.com>; dann frazier <dann.fraz...@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 <a...@kernel.org> wrote: > >> > >> On Thu, 13 Jul 2023 at 18:57, Pedro Falcato <pedro.falc...@gmail.com> > wrote: > >>> > >>> On Tue, Jul 11, 2023 at 7:58 AM Gerd Hoffmann <kra...@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 <o...@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 > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#106926): https://edk2.groups.io/g/devel/message/106926 Mute This Topic: https://groups.io/mt/100057351/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-