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

[osy@turing.llc]

On Mon, Jul 10, 2023 at 8:58 AM Pedro Falcato <pedro.falcato@gmail.com> 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?
> 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?
>
> Personally, I would like to avoid loosening up memory permissions.
>
> --
> Pedro

I agree with the desire to be more secure, but the way I see it is
that the firmware's first priority is to load the bootloader and
gracefully hand off control. The fact that a bootloader is "too old"
shouldn't be a reason to just crash and die. Once downstream projects
like QEMU start picking up this change, this could potentially become
an issue for a lot of users. If the EDK2 project decides that there is
no technical way to both have secure memory permissions and support
older GRUB installs, I think this breakage must be communicated
effectively and be made explicit. I agree that distros probably
shouldn't ship bad GRUBs (here's a bug report in Fedora addressing the
same issue https://bugzilla.redhat.com/show_bug.cgi?id=2149020) and
perhaps they have already fixed it but at the end of the day, the UEFI
firmware likely isn't maintained by the distros. When a user updates
their firmware (from QEMU or from a board vendor), they don't expect
their OS to stop booting. If this happened on real hardware, it could
actually be a real pain to downgrade the firmware or recover and
update GRUB.