Re: backport request

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Jul 25, 2023 at 02:51:56PM +0200, Ard Biesheuvel wrote:
> On Tue, 25 Jul 2023 at 14:29, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Jul 25, 2023 at 01:13:34PM +0200, Ard Biesheuvel wrote:
> > > Please backport commit
> > >
> > > commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1
> > > Author: Ard Biesheuvel <ardb@kernel.org>
> > > Date:   Tue Aug 2 11:00:16 2022 +0200
> > >
> > >     efi: libstub: use EFI_LOADER_CODE region when moving the kernel in memory
> > >
> > > to all active stable trees all the way back to v5.15. I will provide a
> > > separate backport for v5.10, and possibly a [much] larger set of
> > > backports for v5.4 for EFI boot support.
> >
> > Sure, but why?  That sounds like a new feature, if you want EFI boot
> > support, why not just move to a newer kernel tree?  What bug is this
> > fixing?
> >
> 
> Perhaps it is something that the distros just needs to carry in their
> forks, then.
> 
> This is related to distro forks of grub and shim, and the royal mess
> they created on x86. We are making progress on the GRUB side to move
> to the much simpler and cleaner generic EFI stub support that works
> for x86, ARM, arm64, RISC-V and LoongArch. The problem is that the
> distros have a huge set of patches between them that turn shim, GRUB
> and the way x86 boots in a huge tangled mess, and they cannot phase
> those out as long as they need to support older kernels, and so they
> are now in a situation where they need to support all of the above.
> 
> v5.4 is the only release where it is somewhat feasible to backport the
> changes [0] that would allow those GRUB out-of-tree hacks to be
> dropped. I.e., the number of backported patches is quite substantial
> but there are very few and minor conflicts, and the changes are
> confined to EFI code. Backporting this stuff from ~v5.8 to v5.4 would
> mean they can accelerate their phase out schedule by a year.
> (Actually, they asked me about v4.4 but anything older than v5.4 is
> really out of the question)
> 
> In any case, I promised them to take a look and I did - I won't be the
> one pushing for this to get merged.

I think this is up to the distros if they want to deal with this mess on
their older kernels.  They created it, and they want to maintain it as
their "value add", so let's let them earn that value :)

So I'll not add these to any older kernels, they can use 6.1.y instead
if they want to.

thanks,

greg k-h