kpatch dynamic kernel patching

kpatch: dynamic kernel patching

kpatch is a Linux dynamic kernel patching infrastructure which allows you to patch a running kernel without rebooting or restarting any processes. It enables sysadmins to apply critical security patches to the kernel immediately, without having to wait for long-running tasks to complete, for users to log off, or for scheduled reboot windows. It gives more control over uptime without sacrificing security or stability.
kpatch 是一种 Linux 动态内核补丁的基础架构，它允许你在不重启或重新启动任何进程的情况下为运行中的内核打补丁。 它能让系统管理员立即为内核打上重要的安全补丁，而不必等待长时间运行的任务完成、用户注销或预定的重启窗口。 它能在不牺牲安全性或稳定性的情况下，对正常运行时间进行更多控制。

WARNING: Use with caution! Kernel crashes, spontaneous reboots, and data loss may occur!

Here’s a video of kpatch in action:

And a few more:

• https://www.youtube.com/watch?v=rN0sFjrJQfU
• https://www.youtube.com/watch?v=Mftc80KyjA4

Table of contents

• Supported Architectures
• Installation
• Quick start
• Patch Author Guide
• How it works
  • kpatch-build
• Limitations
• Frequently Asked Questions
• Get involved
• License

Supported Architectures

• x86-64
• ppc64le
• arm64
• s390 upstream prerequisites

Installation

See INSTALL.md.

Quick start

NOTE: While kpatch is designed to work with any recent Linux kernel on any distribution, kpatch-build has specifically been tested and
confirmed to work on Fedora and RHEL. It has also been known to work on Oracle Linux, Ubuntu, Debian, and Gentoo.
注意: 虽然 kpatch 可以在任何发行版的任何最新 Linux 内核上运行，但 kpatch-build 已经过专门测试，并确认可以在 Fedora 和 RHEL 上运行。它还可以在 Oracle Linux、Ubuntu、Debian 和 Gentoo 上运行。

First, make a source code patch against the kernel tree using diff, git, or quilt.
首先，使用 diff、git 或 quilt 对内核树进行源代码patch。

As a contrived example, let’s patch /proc/meminfo to show VmallocChunk in ALL CAPS so we can see it better:
举个蹩脚的例子，让我们给 /proc/meminfo 打上补丁，用大写字母显示 VmallocChunk，这样就能看得更清楚了：

$ cat meminfo-string.patch
Index: src/fs/proc/meminfo.c
===================================================================
--- src.orig/fs/proc/meminfo.c
+++ src/fs/proc/meminfo.c
@@ -95,7 +95,7 @@ static int meminfo_proc_show(struct seq_
 "Committed_AS:   %8lu kB\n"
 "VmallocTotal:   %8lu kB\n"
 "VmallocUsed:    %8lu kB\n"
-"VmallocChunk:   %8lu kB\n"
+"VMALLOCCHUNK:   %8lu kB\n"
 #ifdef CONFIG_MEMORY_FAILURE
 "HardwareCorrupted: %5lu kB\n"
 #endif

Build the patch module:

$ kpatch-build meminfo-string.patch
Using cache at /home/jpoimboe/.kpatch/3.13.10-200.fc20.x86_64/src
Testing patch file
checking file fs/proc/meminfo.c
Building original kernel
Building patched kernel
Detecting changed objects
Rebuilding changed objects
Extracting new and modified ELF sections
meminfo.o: changed function: meminfo_proc_show
Building patch module: livepatch-meminfo-string.ko
SUCCESS

That outputs a patch module named kpatch-meminfo-string.ko in the current directory. Now apply it to the running kernel:
这将在当前目录下输出一个名为 kpatch-meminfo-string.ko 的补丁模块。 现在将其应用到运行中的内核：

$ sudo kpatch load kpatch-meminfo-string.ko
loading patch module: livepatch-meminfo-string.ko

Done! The kernel is now patched.
完成！ 内核现已打好补丁。

$ grep -i chunk /proc/meminfo
VMALLOCCHUNK:   34359337092 kB

Patch author guide

Unfortunately, live patching isn’t always as easy as the previous example, and can have some major pitfalls if you’re not careful. To learn more about how to properly create live patches, see the Patch Author Guide.
不幸的是，实时补丁并不总是像前面的例子那么简单，稍有不慎就会有一些重大隐患。 要进一步了解如何正确创建实时补丁，请参阅 [Patch Author Guide]。

How it works

kpatch works at a function granularity: old functions are replaced with new ones. It has three main components:
kpatch 在函数粒度上工作：用新函数替换旧函数。 它有三个主要组件：

• kpatch-build: a collection of tools which convert a source diff patch to a patch module. They work by compiling the kernel both with and without the source patch, comparing the binaries, and generating a patch module which includes new binary versions of the functions to be replaced.

• kpatch-build：将源差异补丁转换为补丁模块的工具集合。 它们的工作原理是编译内核时，同时编译有源补丁和无源补丁的内核，比较二进制文件，然后生成补丁模块，其中包括要替换的函数的新二进制版本。

• patch module: a kernel livepatch module (.ko file) which includes the replacement functions and metadata about the original functions. Upon loading, it registers itself with the kernel livepatch infrastructure (CONFIG_LIVEPATCH) which does the patching.

• 补丁模块：内核实时补丁模块（.ko 文件），包含替换函数和原始函数的元数据。加载后，它将向内核实时补丁基础架构（CONFIG_LIVEPATCH）注册，后者将执行补丁操作。

• kpatch utility: a command-line tool which allows a user to manage a collection of patch modules. One or more patch modules may be configured to load at boot time, so that a system can remain patched even after a reboot into the same version of the kernel.

• kpatch 工具： 一种命令行工具，允许用户管理补丁模块集合。 一个或多个补丁模块可配置为在启动时加载，这样即使系统重启到同一版本的内核中，也能保持补丁状态。

kpatch-build

The “kpatch-build” command converts a source-level diff patch file to a kernel patch module. Most of its work is performed by the kpatch-build script which uses a utility named create-diff-object to compare changed objects.
"kpatch-build"命令将源代码级的差异补丁文件转换为内核补丁模块。大部分工作由 kpatch-build 脚本完成，该脚本使用名为 create-diff-object 的工具来比较更改的对象。

The primary steps in kpatch-build are:
kpatch-build 的主要步骤是

• Build the unstripped vmlinux for the kernel
• 为内核构建未剥离的 vmlinux
• Patch the source tree
• 为源代码树打补丁
• Rebuild vmlinux and monitor which objects are being rebuilt. These are the “changed objects”.
• 重建 vmlinux 并监控哪些对象正在重建。这些就是 “已更改的对象”。
• Recompile each changed object with -ffunction-sections -fdata-sections, resulting in the changed patched objects
• 用 -ffunction-sections -fdata-sections重新编译每个已更改的对象，生成已修补的对象
• Unpatch the source tree
• Recompile each changed object with -ffunction-sections -fdata-sections, resulting in the changed original objects
• For every changed object, use create-diff-object to do the following:
• 对于每个更改后的对象，使用 create-diff-object 执行以下操作：
  • Analyze each original/patched object pair for patchability
  • 分析每个原始/修补对象对的可修补性
  • Add .kpatch.funcs and .rela.kpatch.funcs sections to the output object. The kpatch core module uses this to determine the list of functions that need to be redirected using ftrace.
  • 在输出对象中添加 .kpatch.funcs 和 .rela.kpatch.funcs 部分。kpatch 核心模块会使用它来确定需要使用 ftrace 重定向的函数列表。
  • Add .kpatch.dynrelas and .rela.kpatch.dynrelas sections to the output object. This will be used to resolve references to non-included local and non-exported global symbols. These relocations will be resolved by the kpatch core module.
  • 在输出对象中添加 .kpatch.dynrelas 和 .rela.kpatch.dynrelas 段。这将用于解决对非包含的本地和非导出的全局符号的引用。这些重定位将由 kpatch 核心模块解决。
  • Generate the resulting output object containing the new and modified sections
  • 生成包含新增和修改部分的输出对象
• Link all the output objects into a cumulative object
• 将所有输出对象连接成一个累积对象
• Generate the patch module
• 生成补丁模块

Limitations

• NOTE: Many of these limitations can be worked around with creative solutions. For more details, see the Patch Author Guide.

• 注意：许多限制都可以通过创造性的解决方案来解决。更多详情，请参阅 Patch Author Guide。

• Patches which modify init functions (annotated with __init) are not supported. kpatch-build will return an error if the patch attempts to do so.

• 不支持修改 init 函数 (注释为 __init) 的补丁。如果补丁试图这样做，kpatch-build 将返回错误。

• Patches which modify statically allocated data are not directly supported. kpatch-build will detect that and return an error. This limitation can be overcome by using callbacks or shadow variables, as described in the Patch Author Guide.

• 不直接支持修改静态分配数据的补丁，kpatch-build 会检测到并返回错误。 这一限制可以通过使用回调或影子变量来克服，详见 Patch Author Guide 。

• Patches which change the way a function interacts with dynamically allocated data might be safe, or might not. It isn’t possible for kpatch-build to verify the safety of this kind of patch. It’s up to the user to understand what the patch does, whether the new functions interact with dynamically allocated data in a different way than the old functions did, and whether it would be safe to atomically apply such a patch to a running kernel.

• 改变函数与动态分配数据交互方式的补丁可能是安全的，也可能是不安全的。 kpatch-build 无法验证这类补丁的安全性。 用户需要了解补丁的作用，新函数与动态分配数据的交互方式是否与旧函数不同，以及在运行中的内核中原子地应用这样的补丁是否安全。

• Patches which modify functions in vdso are not supported. These run in user-space and ftrace can’t hook them.

• 不支持修改 vdso 中函数的补丁。这些补丁在用户空间运行，ftrace 无法钩住它们。

• Patches which modify functions that are missing a fentry call are not supported. This includes any lib-y targets that are archived into a lib.a library for later linking (for example, lib/string.o).

• 不支持修改缺少 fentry 调用的函数的补丁。这包括任何归档到 lib.a 库供以后链接的 lib-y 目标（例如 lib/string.o）。

• Some incompatibilities currently exist between kpatch and usage of ftrace and kprobes. See the Frequently Asked Questions section for more details.

• 目前，kpatch 与使用 ftrace 和 kprobes 之间存在一些不兼容问题。更多详情，请参阅常见问题部分。

Frequently Asked Questions

Q. Isn’t this just a virus/rootkit injection framework?

kpatch uses kernel modules to replace code. It requires the CAP_SYS_MODULE capability. If you already have that capability, then you already have the ability to arbitrarily modify the kernel, with or without kpatch.
kpatch 使用内核模块替换代码。它需要 CAP_SYS_MODULE 能力。 如果你已经拥有了这种能力，那么无论有没有 kpatch，你都已经拥有了任意修改内核的能力。

Q. How can I detect if somebody has patched the kernel?

If a patch is currently applied, you can see it in /sys/kernel/livepatch.
如果当前应用了补丁，则可在 /sys/kernel/livepatch中查看。

Also, if a patch has been previously applied, the TAINT_LIVEPATCH flag is set. To test for these flags, cat /proc/sys/kernel/tainted and check to see if the value of TAINT_LIVEPATCH (32768) has been OR’ed in.
此外，如果先前已打上补丁，则会设置 TAINT_LIVEPATCH 标志。 要测试这些标志，可使用 cat /proc/sys/kernel/tainted 并检查 TAINT_LIVEPATCH (32768) 的值是否已被 OR’ed。

Note that the TAINT_OOT_MODULE flag (4096) will also be set, since the patch module is built outside the Linux kernel source tree.
请注意，TAINT_OOT_MODULE 标志 (4096) 也将被设置，因为补丁模块是在 Linux 内核源代码树之外构建的。

If your patch module is unsigned, the TAINT_UNSIGNED_MODULE flag (8192) will also be set.
如果您的补丁模块是无符号的，则也会设置 TAINT_UNSIGNED_MODULE 标志 (8192)。

Q. Will it destabilize my system?

No, as long as the patch is created carefully. See the Limitations section above and the Patch Author Guide.
不会，只要补丁制作得小心谨慎。 请参阅上文 "限制 "部分和补丁编写指南。

Q. Why not use something like kexec instead?

If you want to avoid a hardware reboot, but are ok with restarting processes or using CRIU, kexec is a good alternative.
如果你想避免硬件重启，但又能接受重启进程或使用 CRIU，kexec 是一个不错的选择。

Q. If an application can’t handle a reboot, it’s designed wrong.

That’s a good poi… [system reboots]

Q. What kernels are supported?

kpatch needs gcc >= 4.8 and Linux >= 4.0.

Q. Is it possible to remove a patch?

Yes. Just run kpatch unload which will disable and unload the patch module and restore the function to its original state.
可以。 只需运行 kpatch unload 即可禁用和卸载补丁模块，并将功能恢复到初始状态。

Q. Can you apply multiple patches?

Yes, but to prevent any unexpected interactions between multiple patch modules, it’s recommended that patch upgrades are cumulative, so that each patch is a superset of the previous patch. This can be achieved by combining the new patch with the previous patch using combinediff before running kpatch-build. It’s also recommended to use livepatch atomic “replace” mode, which is the default.
是的，但为了防止多个补丁模块之间出现意外的交互，建议补丁升级采用累积方式，这样每个补丁都是前一个补丁的超集。这可以通过在运行 kpatch-build 之前使用 combinediff 将新补丁与上一个补丁合并来实现。 我们还建议使用 livepatch 原子 "替换 "模式，这是默认模式。

Q. Why did kpatch-build detect a changed function that wasn’t touched by the source patch?

There could be a variety of reasons for this, such as:
这可能有多种原因，例如

• The patch changed an inline function.
• 补丁更改了一个内联函数。
• The compiler decided to inline a changed function, resulting in the outer function getting recompiled. This is common in the case where the inner function is static and is only called once.
• 编译器决定内联一个已更改的函数，导致外层函数被重新编译。 在内部函数是静态函数且只被调用一次的情况下，这种情况很常见。
• A bug in kpatch-build’s detection of __LINE__ macro usage.
• kpatch-build 检测 __LINE__ 宏使用时的一个错误。

Q. Are patching of kernel modules supported?

• Yes.

Q. Can you patch out-of-tree modules?

Yes! There’s a few requirements, and the feature is still in its infancy.
可以！有一些要求，而且该功能仍处于起步阶段。

1. You need to use the --oot-module flag to specify the version of the module that’s currently running on the machine.
   你需要使用 --oot-module 标记来指定当前机器上运行的模块版本。
2. --oot-module-src has to be passed with a directory containing the same version of code as the running module, all set up and ready to build with a make command. For example, some modules need autogen.sh and ./configure to have been run with the appropriate flags to match the currently-running module.
   --oot-module-src 必须与包含与正在运行的模块相同版本代码的目录一起传递，所有代码都已设置好，可以用 make 命令编译。例如，有些模 块需要 autogen.sh 和 ./configure在运行时加上适当的标志，以匹配当前运行的模块。
3. If the Module.symvers file for the out-of-tree module doesn’t appear in the root of the provided source directory, a symlink needs to be created in that directory that points to its actual location.
   如果out-of-tree模块的 Module.symvers 文件不在提供的源代码目录根目录中，则需要在该目录中创建一个指向其实际位置的软链接。
4. Usually you’ll need to pass the --target flag as well, to specify the proper make target names.
   通常还需要传递 --target 标志，以指定适当的 make 目标名称。
5. This has only been tested for a single out-of-tree module per patch, and not for out-of-tree modules with dependencies on other out-of-tree modules built separately.
   这只针对每个补丁中的单个out-of-tree模块进行了测试，而不是针对依赖于单独构建的其他out-of-tree模块的out-of-tree模块。

Sample invocation

kpatch-build --oot-module-src ~/test/ --target default --oot-module /lib/modules/$(uname -r)/extra/test.ko test.patch

Q. What is needed to support a new architecture?

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.
   在内核中添加 CONFIG_HAVE_LIVEPATCH 支持。对于某些架构，这可能就像启用 CONFIG_DYNAMIC_FTRACE_WITH REGS 一样简单。有了这种支持，您就可以制作基本的如 samples/livepatch 中的补丁一样的实时补丁了。Livepatch 功能是有限制的，必须格外小心以避免某些陷阱。
2. Add kpatch-build (create-diff-object) support. This makes it easier to build patches, and avoids some of the pitfalls. For example,
   https://github.com/dynup/kpatch/pull/1203 added s390x support.
   添加 kpatch-build（创建-diff-对象）支持。这样就能更容易地构建补丁，并避免一些陷阱。 例如
   https://github.com/dynup/kpatch/pull/1203 添加了 对 s390x 的支持。
3. Add CONFIG_HAVE_RELIABLE_STACKTRACE and (if needed) objtool support in the kernel. This avoids more pitfalls and enables full livepatch functionality.
   在内核中添加 CONFIG_HAVE_RELIABLE_STACKTRACE 和 objtool 支持（如需要）。这样可以避免更多陷阱，并实现完整的实时补丁功能。

Get involved

If you have questions or feedback, join the #kpatch IRC channel on Libera and say hi.
如果您有问题或反馈，请加入 Libera 上的 #kpatch IRC 频道并打招呼。

Contributions are very welcome. Feel free to open issues or PRs on github. For big PRs, it’s a good idea to discuss them first in github issues/discussions or on IRC before you write a lot of code.
我们非常欢迎您的贡献。 欢迎在 github 上打开问题或 PR。对于大型 PR，在编写大量代码之前，最好先在 github 问题/讨论或 IRC 上进行讨论。

License

kpatch is under the GPLv2 license.
kpatch 采用 GPLv2 许可协议。

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
本程序是自由软件；您可以根据自由软件基金会发布的 GNU 通用公共许可证条款重新发布和/或修改本程序；可以是许可证的第 2 版，也可以是（由您选择的）任何后续版本。

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
本程序在发布时是希望其可用的，但不附带任何保证；甚至不附带适销性或特定用途适用性的默示保证。 更多详情，请参阅 GNU 通用公共许可证。

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
您应该随本程序一起收到一份 GNU 通用公共许可证副本；如果没有，请写信给自由软件基金会 (Free Software Foundation, Inc.), 51 Franklin Street, Five Floor, Boston, MA 02110-1301, USA。

原文地址：https://blog.csdn.net/u014100559/article/details/140278351

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！