From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E5DCC001DF for ; Tue, 25 Jul 2023 13:22:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230054AbjGYNV7 (ORCPT ); Tue, 25 Jul 2023 09:21:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230060AbjGYNV6 (ORCPT ); Tue, 25 Jul 2023 09:21:58 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 978E1E3 for ; Tue, 25 Jul 2023 06:21:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 358C3616F6 for ; Tue, 25 Jul 2023 13:21:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 20415C433C7; Tue, 25 Jul 2023 13:21:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1690291316; bh=g43iLn0GYalcb1dWTyWyle17lKpYpYHC27Lj6ExKK1Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=xqyCG+wbXN2sx795a6bqgF1D8sR65awPAmN+pXzPFp6Ebu9QkXJl3gKGmmeMzWfex Uy4GzlzfIx/W+4ZWLYahOi80eDDFnbRHklXjkOuflhneUWqmtuX9sl+5W0l11ip09k 2Nt9mAikpdWGjDoyBb5gW2Ej97uZaY7bHS5vprx4= Date: Tue, 25 Jul 2023 15:21:53 +0200 From: Greg KH To: Ard Biesheuvel Cc: "# 3.4.x" Subject: Re: backport request Message-ID: <2023072527-dehydrate-frown-3312@gregkh> References: <2023072521-refurnish-grooving-fd36@gregkh> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Tue, Jul 25, 2023 at 02:51:56PM +0200, Ard Biesheuvel wrote: > On Tue, 25 Jul 2023 at 14:29, Greg KH wrote: > > > > On Tue, Jul 25, 2023 at 01:13:34PM +0200, Ard Biesheuvel wrote: > > > Please backport commit > > > > > > commit 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1 > > > Author: Ard Biesheuvel > > > 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