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