What do I need to do to support riscv64? about kpatch HOT 11 CLOSED

To support RISC-V in live patching, you need much more that updating kpatch tools.

Many things need to be done at the kernel side, e.g. to make stack traces reliable, etc.

You can take a look at the activities to add livepatch support for ARM:
https://lore.kernel.org/linux-arm-kernel/[email protected]/T/
https://lwn.net/Articles/890741/

from kpatch.

I guess, reliable kernel stack traces and support for RISC-V in objtool are the areas to start to eventually enable livepatch on this architecture. Likely, doable but not that easy.

from kpatch.

from kpatch.

I'd suggest to learn how they did it for ARM first, see my earlier comment (#1296 (comment)).

from kpatch.

By the way, I am very interested in having livepatch on RISC-V too.

I'll gladly help in reviewing and testing of the related patches, at least. I mean, the patches both to the kernel and to the kpatch tools.

from kpatch.

Porting an architecture can be done in three phases:

1. In the kernel, add CONFIG_HAVE_LIVEPATCH support. For some arches this might be as simple as enabling CONFIG_DYNAMIC_FTRACE_WITH REGS. With this support you can do basic live patches like those in samples/livepatch. Livepatch functionality is limited and extra care must be taken to avoid certain pitfalls.

2. Add kpatch-build (create-diff-object) support. This makes it easier to build patches, and avoids some of the pitfalls.

3. Add CONFIG_HAVE_RELIABLE_STACKTRACE and (if needed) objtool support in the kernel. This avoids more pitfalls and enables full livepatch functionality.

from kpatch.

@jpoimboe Thanks!

As far as RISC-V is concerned,

1. DYNAMIC_FTRACE_WITH REGS seems to be supported, one needs to enable it, test if it works OK and report/fix the bugs.
2. kpatch-build (create-diff-object) support - IMO, this is mostly about RISC-V-specific relocations, special sections (if any) and, may be, detection of WARN() and such. Looks doable.
3. CONFIG_HAVE_RELIABLE_STACKTRACE & objtool - the most difficult and time-consuming part, I think. And absolutely critical for production use. This is why I'd suggest to deal with is first.

from kpatch.

• kpatch-build (create-diff-object) support - IMO, this is mostly about RISC-V-specific relocations, special sections (if any) and, may be, detection of WARN() and such. Looks doable.

Yes, the s390 port turned out to be quite small, the kpatch-build code base seems to have become quite arch-friendly.

• CONFIG_HAVE_RELIABLE_STACKTRACE & objtool - the most difficult and time-consuming part, I think. And absolutely critical for production use. This is why I'd suggest to deal with is first.

Many patches don't need the livepatch "consistency model". If the patch author knows what they're doing and is careful, the reliable stack tracing isn't needed in many cases.

from kpatch.

Since the question was answered and high-level steps documented in #1297, is there anything more to track in this issue?

from kpatch.

I think this one can be closed. The issues with particular steps to add support for RISC-V (checking Ftrace, adapting objtool, etc.) should be tracked separately when they arise.

from kpatch.

1. In the kernel, add CONFIG_HAVE_LIVEPATCH support. For some arches this might be as simple as enabling CONFIG_DYNAMIC_FTRACE_WITH REGS. With this support you can do basic live patches like those in samples/livepatch. Livepatch functionality is limited and extra care must be taken to avoid certain pitfalls.

A quick update:

• CONFIG_DYNAMIC_FTRACE_WITH_REGS is currently (linux 6.2-rc1) broken w.r.t. FTRACE_OPS_FL_IPMODIFY on RISC-V.
  This patch fixes the issue as a side-effect: https://lkml.iu.edu/hypermail/linux/kernel/2212.1/00200.html.

• CONFIG_HAVE_LIVEPATCH needs a bit more work here.
  First, it turned out that livepatch actually requires CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS (not sure if that is intentional). With CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS unset, even if CONFIG_DYNAMIC_FTRACE_WITH_REGS=y, ftrace_instruction_pointer_set() is a no-op, and control redirection to the new function does not happen.
  There are a few more things to be done here and there: thread flags, etc.

I'll experiment with this when I have time.

from kpatch.