On Mon, Jul 10, 2023 at 8:58 AM Pedro Falcato <pedro.falc...@gmail.com> 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?
> 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.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106772): https://edk2.groups.io/g/devel/message/106772
Mute This Topic: https://groups.io/mt/100057351/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
