On Thu, Apr 11, 2024 at 03:14:23PM +0200, Ard Biesheuvel wrote: > On Thu, 11 Apr 2024 at 13:50, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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.
