Re: v5.15 backport request

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Apr 23, 2024 at 01:23:23PM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Apr 11, 2024 at 03:14:23PM +0200, Ard Biesheuvel wrote:
> > On Thu, 11 Apr 2024 at 13:50, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Thu, Apr 11, 2024 at 12:30:30PM +0200, Greg KH wrote:
> > > > On Thu, Apr 11, 2024 at 12:23:37PM +0200, Ard Biesheuvel wrote:
> > > > > Please consider the commits below for backporting to v5.15. These
> > > > > patches are prerequisites for the backport of the x86 EFI stub
> > > > > refactor that is needed for distros to sign v5.15 images for secure
> > > > > boot in a way that complies with new MS requirements for memory
> 
> Secure Boot needn't be enabled.
> > > > > protections while running in the EFI firmware.
> 
> And here is the background:
> https://microsoft.github.io/mu/WhatAndWhy/enhancedmemoryprotection/
> 
> > > >
> > > > What old distros still care about this for a kernel that was released in
> > > > 2021?  I can almost understand this for 6.1.y and newer, but why for
> > > > this one too?
> > >
> > > To be more specific, we have taken very large backports for some
> > > subsystems recently for 5.15 in order to fix a lot of known security
> > > issues with the current codebase, and to make the maintenance of that
> > > kernel easier over time (i.e. keeping it in sync to again, fix security
> > > issues.)
> > >
> > > But this feels like a "new feature" that is being imposed by an external
> > > force, and is not actually "fixing" anything wrong with the current
> > > codebase, other than it not supporting this type of architecture.  And
> > > for that, wouldn't it just make more sense to use a newer kernel?
> > >
> > 
> > Jan (on cc) raised this: apparently, Oracle has v5.15 based long term
> > supported distro releases, and these will not be installable on future
> > x86 PC hardware with secure boot enabled unless the EFI stub changes
> > are backported.
> > 
> > >From my pov, the situation is not that different from v6.1: the number
> > of backports is not that much higher than the number that went/are
> > going into v6.1, and most of the fallout of the v6.1 backport has been
> > addressed by now.
> > 
> > For an operational pov, I need to defer to Jan: I have no idea what
> > OEMs are planning to do wrt these new MS requirements, if they will
> 
> .. snip..
> 
> Hey Greg,
> 
> This is driven by the BlackLotus exploit and alike to fix boot-time
> security lapses. From a risk perspective it is boot-time code so it is
> very easy to figure out if it backports are busted.
> 
> In terms of OEMs, it is actually more of a cloud vendor wanting to roll
> this soon-ish and that combined with our customers worshipping these
> crusty old 5.15 kernels that puts us in this situation.

I think that worship needs to stop when they desire massive new features
like this, sorry.  Please have them move to the 6.1 kernel tree instead
if they wish to care about this type of thing, or better yet, 6.6.

thanks,

greg k-h