On Tue, 25 Jul 2023 at 15:41, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Jul 25, 2023 at 03:25:35PM +0200, Ard Biesheuvel wrote: > > On Tue, 25 Jul 2023 at 15:21, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Tue, Jul 25, 2023 at 02:51:56PM +0200, Ard Biesheuvel wrote: > > > > On Tue, 25 Jul 2023 at 14:29, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > On Tue, Jul 25, 2023 at 01:13:34PM +0200, Ard Biesheuvel wrote: > > > > > > Please backport commit > > > > > > > > > > > > commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1 > > > > > > Author: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > > > > 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. > > > > > > > Yes, but please backport commit > > 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1 nonetheless - that one is an > > obvious bug fix. > > Ok, will do after this round of releases are done. > Actually, no - please disregard. I confused myself here - the fix is fine, just not needed for v5.10 - v6.4. Sorry for the noise.
