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.