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.
All patches either predate v6.1 or have been backported to it already. The remaining ~50 changes will be posted as a patch series in due time, as they will not apply cleanly to v5.15.
Please apply in the order that they appear below.
Thanks, Ard.
44f155b4b07b8293472c9797d5b39839b91041ca 4da87c51705815fe1fbd41cc61640bb80da5bc54 7c4146e8885512719a50b641e9277a1712e052ff 176db622573f028f85221873ea4577e096785315 950d00558a920227b5703d1fcc4751cfe03853cd ec1c66af3a30d45c2420da0974c01d3515dba26e a9ee679b1f8c3803490ed2eeffb688aaee56583f 3ba75c1316390b2bc39c19cb8f0f85922ab3f9ed 82e0d6d76a2a74bd6a31141d555d53b4cc22c2a3 31f1a0edff78c43e8a3bd3692af0db1b25c21b17 9cf42bca30e98a1c6c9e8abf876940a551eaa3d1 cb8bda8ad4438b4bcfcf89697fc84803fb210017 e2ab9eab324cdf240de89741e4a1aa79919f0196 5c3a85f35b583259cf5ca0344cd79c8899ba1bb7 91592b5c0c2f076ff9d8cc0c14aa563448ac9fc4 73a6dec80e2acedaef3ca603d4b5799049f6e9f8 7f22ca396778fea9332d83ec2359dbe8396e9a06 4b52016247aeaa55ca3e3bc2e03cd91114c145c2 630f337f0c4fd80390e8600adcab31550aea33df db14655ad7854b69a2efda348e30d02dbc19e8a1 bad267f9e18f8e9e628abd1811d2899b1735a4e1 62b71cd73d41ddac6b1760402bbe8c4932e23531 cc3fdda2876e58a7e83e558ab51853cf106afb6a d2d7a54f69b67cd0a30e0ebb5307cb2de625baac
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?
thanks,
greg k-h
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?
thanks,
greg k-h
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.
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.
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
linux-stable-mirror@lists.linaro.org
-
Ard Biesheuvel -
Greg KH -
Konrad Rzeszutek Wilk