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 protections while running in the EFI firmware.
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 apply to existing systems with firmware upgrades, and if those newer systems can run on v5.15 to begin with.
@Jan: if this v5.15 backport is important to you, please provide some more background on why and how this is needed.
Thanks, Ard.