There are recent efforts to enable livepatch for arm64, with sframe [1] or
without sframe [2]. This set tries to enable livepatch without sframe. Some
of the code, however, are from [1].

Although the sframe implementation is more promising in longer term, it
suffers from the following issues:

  1. sframe is not yet supported in llvm;
  2. There is still bug in binutil [3], so that we cannot yet use sframe
     with gcc;
  3. sframe unwinder hasn't been fully verified in the kernel.

On the other hand, arm64 processors have become more and more important in
the data center world. Therefore, it is getting critical to support
livepatching of arm64 kernels.

With recent change in arm64 unwinder [4], it is possible to reliably
livepatch arm64 kernels without sframe. This is because we do not need
arch_stack_walk_reliable() to get reliable stack trace in all scenarios.
Instead, we only need arch_stack_walk_reliable() to detect when the
stack trace is not reliable, then the livepatch logic can retry the patch
transition at a later time.

Given the increasing need of livepatching, and relatively long time before
sframe is fully ready (for both gcc and clang), we would like to enable
livepatch without sframe.

Thanks!

[1] https://lore.kernel.org/live-patching/20250127213310.2496133-1-wnliu@google.com/
[2] https://lore.kernel.org/live-patching/20250129232936.1795412-1-song@kernel.org/
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=32589
[4] https://lore.kernel.org/linux-arm-kernel/20241017092538.1859841-1-mark.rutland@arm.com/

Changes v2 => v3:
1. Remove a redundant check for -ENOENT. (Josh Poimboeuf)
2. Add Tested-by and Acked-by on v1. (I forgot to add them in v2.)

v2: https://lore.kernel.org/live-patching/20250319213707.1784775-1-song@kernel.org/

Changes v1 => v2:

1. Rework arch_stack_walk_reliable().

v1: https://lore.kernel.org/live-patching/20250308012742.3208215-1-song@kernel.org/

Song Liu (2):
  arm64: Implement arch_stack_walk_reliable
  arm64: Implement HAVE_LIVEPATCH

 arch/arm64/Kconfig                   |  3 ++
 arch/arm64/include/asm/thread_info.h |  4 +-
 arch/arm64/kernel/entry-common.c     |  4 ++
 arch/arm64/kernel/stacktrace.c       | 66 +++++++++++++++++++++-------
 4 files changed, 60 insertions(+), 17 deletions(-)

--
2.47.1

On Thu 2025-03-20 10:15:57, Song Liu wrote:
> There are recent efforts to enable livepatch for arm64, with sframe [1] or
> without sframe [2]. This set tries to enable livepatch without sframe. Some
> of the code, however, are from [1].
> 
> Although the sframe implementation is more promising in longer term, it
> suffers from the following issues:
> 
>   1. sframe is not yet supported in llvm;
>   2. There is still bug in binutil [3], so that we cannot yet use sframe
>      with gcc;
>   3. sframe unwinder hasn't been fully verified in the kernel.
> 
> On the other hand, arm64 processors have become more and more important in
> the data center world. Therefore, it is getting critical to support
> livepatching of arm64 kernels.
> 
> With recent change in arm64 unwinder [4], it is possible to reliably
> livepatch arm64 kernels without sframe. This is because we do not need
> arch_stack_walk_reliable() to get reliable stack trace in all scenarios.
> Instead, we only need arch_stack_walk_reliable() to detect when the
> stack trace is not reliable, then the livepatch logic can retry the patch
> transition at a later time.
> 
> Given the increasing need of livepatching, and relatively long time before
> sframe is fully ready (for both gcc and clang), we would like to enable
> livepatch without sframe.
> 
> Thanks!
> 
> [1] https://lore.kernel.org/live-patching/20250127213310.2496133-1-wnliu@google.com/
> [2] https://lore.kernel.org/live-patching/20250129232936.1795412-1-song@kernel.org/
> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=32589
> [4] https://lore.kernel.org/linux-arm-kernel/20241017092538.1859841-1-mark.rutland@arm.com/
> 
> Changes v2 => v3:
> 1. Remove a redundant check for -ENOENT. (Josh Poimboeuf)
> 2. Add Tested-by and Acked-by on v1. (I forgot to add them in v2.)

The approach and both patches look reasonable:

Reviewed-by: Petr Mladek <pmladek@suse.com>

Is anyone, Arm people, Mark, against pushing this into linux-next,
please?

Best Regards,
Petr

On Thu, Apr 10, 2025 at 8:17 AM Petr Mladek <pmladek@suse.com> wrote:
>
[...]
> >
> > [1] https://lore.kernel.org/live-patching/20250127213310.2496133-1-wnliu@google.com/
> > [2] https://lore.kernel.org/live-patching/20250129232936.1795412-1-song@kernel.org/
> > [3] https://sourceware.org/bugzilla/show_bug.cgi?id=32589
> > [4] https://lore.kernel.org/linux-arm-kernel/20241017092538.1859841-1-mark.rutland@arm.com/
> >
> > Changes v2 => v3:
> > 1. Remove a redundant check for -ENOENT. (Josh Poimboeuf)
> > 2. Add Tested-by and Acked-by on v1. (I forgot to add them in v2.)
>
> The approach and both patches look reasonable:
>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
>
> Is anyone, Arm people, Mark, against pushing this into linux-next,
> please?

Ping.

ARM folks, please share your thoughts on this work. To fully support
livepatching of kernel modules, we also need [1]. We hope we can
land this in the 6.16 kernel.

Thanks,
Song

[1] https://lore.kernel.org/linux-arm-kernel/20250412010940.1686376-1-dylanbhatch@google.com/

On Fri, May 16, 2025 at 09:53:36AM -0700, Song Liu wrote:
> ARM folks, please share your thoughts on this work. To fully support
> livepatching of kernel modules, we also need [1]. We hope we can
> land this in the 6.16 kernel.
> 
> Thanks,
> Song
> 
> [1] https://lore.kernel.org/linux-arm-kernel/20250412010940.1686376-1-dylanbhatch@google.com/

I've had a quick look at [1], and IIUC that's a hard prerequisite for
livepatching, as without it the kernel *will* crash if it attempts a
late module relocation.

Given that, I don't think that we can take patch 2 until Will's comments
on [1] have been addressed, but I think that we could take patch 1 (with
fixups) as per my other reply.

Mark.

> FWIW: I reviewed the patch above ([1]) already but didn't hear anything
> back.

Sorry for the delay on this, last week was busier than expected on my
end. I'm aiming to send the revised patch within the next couple of
days.

On Mon, May 19, 2025 at 9:40 AM Mark Rutland <mark.rutland@arm.com> wrote:
> I've had a quick look at [1], and IIUC that's a hard prerequisite for
> livepatching, as without it the kernel *will* crash if it attempts a
> late module relocation.
>

This is correct. In both module-patch scenarios (module is loaded
first, or patch is loaded first) the relocations on the livepatch
module occur after it is already RX-only, so a crash is inevitable
with the current relocation code.

Thanks,
Dylan

On Fri, May 16, 2025 at 09:53:36AM -0700, Song Liu wrote:
> On Thu, Apr 10, 2025 at 8:17 AM Petr Mladek <pmladek@suse.com> wrote:
> >
> [...]
> > >
> > > [1] https://lore.kernel.org/live-patching/20250127213310.2496133-1-wnliu@google.com/
> > > [2] https://lore.kernel.org/live-patching/20250129232936.1795412-1-song@kernel.org/
> > > [3] https://sourceware.org/bugzilla/show_bug.cgi?id=32589
> > > [4] https://lore.kernel.org/linux-arm-kernel/20241017092538.1859841-1-mark.rutland@arm.com/
> > >
> > > Changes v2 => v3:
> > > 1. Remove a redundant check for -ENOENT. (Josh Poimboeuf)
> > > 2. Add Tested-by and Acked-by on v1. (I forgot to add them in v2.)
> >
> > The approach and both patches look reasonable:
> >
> > Reviewed-by: Petr Mladek <pmladek@suse.com>
> >
> > Is anyone, Arm people, Mark, against pushing this into linux-next,
> > please?
> 
> Ping.
> 
> ARM folks, please share your thoughts on this work. To fully support
> livepatching of kernel modules, we also need [1]. We hope we can
> land this in the 6.16 kernel.
> 
> Thanks,
> Song
> 
> [1] https://lore.kernel.org/linux-arm-kernel/20250412010940.1686376-1-dylanbhatch@google.com/


FWIW: I reviewed the patch above ([1]) already but didn't hear anything
back.

Will

On Fri, May 16, 2025 at 09:53:36AM -0700, Song Liu wrote:
> On Thu, Apr 10, 2025 at 8:17 AM Petr Mladek <pmladek@suse.com> wrote:
> >
> [...]
> > >
> > > [1] https://lore.kernel.org/live-patching/20250127213310.2496133-1-wnliu@google.com/
> > > [2] https://lore.kernel.org/live-patching/20250129232936.1795412-1-song@kernel.org/
> > > [3] https://sourceware.org/bugzilla/show_bug.cgi?id=32589
> > > [4] https://lore.kernel.org/linux-arm-kernel/20241017092538.1859841-1-mark.rutland@arm.com/
> > >
> > > Changes v2 => v3:
> > > 1. Remove a redundant check for -ENOENT. (Josh Poimboeuf)
> > > 2. Add Tested-by and Acked-by on v1. (I forgot to add them in v2.)
> >
> > The approach and both patches look reasonable:
> >
> > Reviewed-by: Petr Mladek <pmladek@suse.com>
> >
> > Is anyone, Arm people, Mark, against pushing this into linux-next,
> > please?
> 
> Ping.
> 
> ARM folks, please share your thoughts on this work. To fully support
> livepatching of kernel modules, we also need [1]. We hope we can
> land this in the 6.16 kernel.

Hi; apologies for the delay -- my time had been consumed by
FPSIMD/SVE/SME fixes and related non-upstream stuff for the last few
weeks, and now I'm catching up.

For the stacktrace side, I'm happy with enabling this without sframe,
and I hase some minor nits which we can either fix up now or as a
follow-up. I'll cover those in another reply, and chase up the module /
code-patching bit shortly.

Mark.

> Thanks,
> Song
> 
> [1] https://lore.kernel.org/linux-arm-kernel/20250412010940.1686376-1-dylanbhatch@google.com/

On Thu 2025-03-20 10:15:57, Song Liu wrote:
> There are recent efforts to enable livepatch for arm64, with sframe [1] or
> without sframe [2]. This set tries to enable livepatch without sframe. Some
> of the code, however, are from [1].
> 
> Although the sframe implementation is more promising in longer term, it
> suffers from the following issues:
> 
>   1. sframe is not yet supported in llvm;
>   2. There is still bug in binutil [3], so that we cannot yet use sframe
>      with gcc;
>   3. sframe unwinder hasn't been fully verified in the kernel.
> 
> On the other hand, arm64 processors have become more and more important in
> the data center world. Therefore, it is getting critical to support
> livepatching of arm64 kernels.
> 
> With recent change in arm64 unwinder [4], it is possible to reliably
> livepatch arm64 kernels without sframe. This is because we do not need
> arch_stack_walk_reliable() to get reliable stack trace in all scenarios.
> Instead, we only need arch_stack_walk_reliable() to detect when the
> stack trace is not reliable, then the livepatch logic can retry the patch
> transition at a later time.
> 
> Given the increasing need of livepatching, and relatively long time before
> sframe is fully ready (for both gcc and clang), we would like to enable
> livepatch without sframe.
> 
> Thanks!
> 
> [1] https://lore.kernel.org/live-patching/20250127213310.2496133-1-wnliu@google.com/
> [2] https://lore.kernel.org/live-patching/20250129232936.1795412-1-song@kernel.org/
> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=32589
> [4] https://lore.kernel.org/linux-arm-kernel/20241017092538.1859841-1-mark.rutland@arm.com/

Hi, I am sorry but I haven't found time to look at this in time before
the merge window. Is it acceptable to postpone this change to 6.16,
please?

Best Regards,
Petr

Hi Petr,

> On Mar 25, 2025, at 8:53 AM, Petr Mladek <pmladek@suse.com> wrote:

[...]

>> 
>> Given the increasing need of livepatching, and relatively long time before
>> sframe is fully ready (for both gcc and clang), we would like to enable
>> livepatch without sframe.
>> 
>> Thanks!
>> 
>> [1] https://lore.kernel.org/live-patching/20250127213310.2496133-1-wnliu@google.com/ 
>> [2] https://lore.kernel.org/live-patching/20250129232936.1795412-1-song@kernel.org/ 
>> [3] https://urldefense.com/v3/__https://sourceware.org/bugzilla/show_bug.cgi?id=32589__;!!Bt8RZUm9aw!8CB9ByorcyTxDW3rQ6_GEeMTJN9rHWCydNdIW1FRb_2-LQ6RTrSerZq9E-s8kXEB12JJ_v07xkyc2w$ 
>> [4] https://lore.kernel.org/linux-arm-kernel/20241017092538.1859841-1-mark.rutland@arm.com/
> 
> Hi, I am sorry but I haven't found time to look at this in time before
> the merge window. Is it acceptable to postpone this change to 6.16,
> please?

Yes, we can postpone this to 6.16. I will resend the patchset after 
the merge window.

Thanks,
Song