v5.15 backport request

v5.15 backport request

[Ard Biesheuvel]

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

Re: v5.15 backport request

[Greg KH]

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

Re: v5.15 backport request

[Greg KH]

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

Re: v5.15 backport request

[Ard Biesheuvel]

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.

Re: v5.15 backport request

[Konrad Rzeszutek Wilk]

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.

Re: v5.15 backport request

[Greg KH]

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

v5.15+ backport request

[dcrady]

Please backport the following v6.7 commit:

commit be097997a273 ("KVM: arm64: Always invalidate TLB for stage-2 permission faults")

to stable kernels v5.15 and newer to fix:

It is possible for multiple vCPUs to fault on the same IPA and attempt
to resolve the fault. One of the page table walks will actually update
the PTE and the rest will return -EAGAIN per our race detection scheme.
KVM elides the TLB invalidation on the racing threads as the return
value is nonzero.

Before commit a12ab1378a88 ("KVM: arm64: Use local TLBI on permission
relaxation") KVM always used broadcast TLB invalidations when handling
permission faults, which had the convenient property of making the
stage-2 updates visible to all CPUs in the system. However now we do a
local invalidation, and TLBI elision leads to the vCPU thread faulting
again on the stale entry. Remember that the architecture permits the TLB
to cache translations that precipitate a permission fault.

Invalidate the TLB entry responsible for the permission fault if the
stage-2 descriptor has been relaxed, regardless of which thread actually
did the job.

Thank you!
doug rady

Re: v5.15+ backport request

[Greg KH]

On Mon, Apr 15, 2024 at 08:46:26PM -0700, dcrady@os.amperecomputing.com wrote:
> Please backport the following v6.7 commit:
> 
> commit be097997a273 ("KVM: arm64: Always invalidate TLB for stage-2 permission faults")
> 
> to stable kernels v5.15 and newer to fix:

Any specific reason you didn't cc: the maintainers and developers of
that change with this request?

thanks,

greg k-h

Re: v5.15+ backport request

[Greg KH]

On Tue, Apr 16, 2024 at 06:37:28AM +0200, Greg KH wrote:
> On Mon, Apr 15, 2024 at 08:46:26PM -0700, dcrady@os.amperecomputing.com wrote:
> > Please backport the following v6.7 commit:
> > 
> > commit be097997a273 ("KVM: arm64: Always invalidate TLB for stage-2 permission faults")
> > 
> > to stable kernels v5.15 and newer to fix:
> 
> Any specific reason you didn't cc: the maintainers and developers of
> that change with this request?

Dropping from my review queue and will wait for you to resubmit this.

thanks,

greg k-h

v5.15+ backport request

[Ard Biesheuvel]

please backport

e7d24c0aa8e678f41
gcc-plugins/stackleak: Avoid .head.text section

to stable kernels v5.15 and newer. This addresses the regression reported here:

https://lkml.kernel.org/r/dc118105-b97c-4e51-9a42-a918fa875967%40hardfalcon.net

On v5.15, there is a dependency that needs to be backported first:

ae978009fc013e3166c9f523f8b17e41a3c0286e
gcc-plugins/stackleak: Ignore .noinstr.text and .entry.text

The particular issue that this patch fixes does not exist [yet] in
v6.1 and v5.15, but I am working on backports that would introduce it.
But even without those backports, this change is important as it
prevents input sections from being instrumented by stackleak that may
not tolerate this for other reasons too.

Thanks,
Ard.

Re: v5.15+ backport request

[Greg KH]

On Thu, Apr 11, 2024 at 08:43:35AM +0200, Ard Biesheuvel wrote:
> please backport
> 
> e7d24c0aa8e678f41
> gcc-plugins/stackleak: Avoid .head.text section
> 
> to stable kernels v5.15 and newer. This addresses the regression reported here:
> 
> https://lkml.kernel.org/r/dc118105-b97c-4e51-9a42-a918fa875967%40hardfalcon.net
> 
> On v5.15, there is a dependency that needs to be backported first:
> 
> ae978009fc013e3166c9f523f8b17e41a3c0286e
> gcc-plugins/stackleak: Ignore .noinstr.text and .entry.text
> 
> The particular issue that this patch fixes does not exist [yet] in
> v6.1 and v5.15, but I am working on backports that would introduce it.
> But even without those backports, this change is important as it
> prevents input sections from being instrumented by stackleak that may
> not tolerate this for other reasons too.

All now queued up, thanks.

greg k-h