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?
--
Pedro
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106916): https://edk2.groups.io/g/devel/message/106916
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]
-=-=-=-=-=-=-=-=-=-=-=-
