内核热补丁，真的安全么？
时间：2021-10-09 14:30:47
[导读]Linux内核热补丁可以修复正在运行的linux内核，是一种维持线上稳定性不可缺少的措施，现在比较常见的比如kpatch和livepatch。内核热补丁可以修复内核中正在运行的函数，用已修复的函数替换掉内核中存在问题的函数从而达到修复目的。函数替换的思想比较简单，就是在执行旧函数...
Linux 内核热补丁可以修复正在运行的 linux 内核，是一种维持线上稳定性不可缺少的措施，现在比较常见的比如 kpatch 和 livepatch。内核热补丁可以修复内核中正在运行的函数，用已修复的函数替换掉内核中存在问题的函数从而达到修复目的。函数替换的思想比较简单，就是在执行旧函数时绕开它的执行逻辑而跳转到新的函数中，有一种比较简单粗暴的方式，就是将原函数的第一条指令修改为“ jump 目标函数”指令，即直接跳转到新的函数以达到替换目的。那么，问题来了，这么做靠谱吗？直接将原函数的第一条指令修改为 jump 指令，会破坏掉原函数和它的调用者之间的寄存器上下文关系，存在安全隐患！本文会针对该问题进行探索和验证。
安全性冲击：问题呈现
对于函数调用，假设存在这样两个函数 funA 和 funB，其中 funA 调用 funB 函数，这里称 funA 为 caller（调用者），funB 为 callee（被调用者），funA 和 funB 都使用了相同的寄存器 R，如下所示：图1 funA 和 funB 都使用了寄存器 R，funA 再次使用 R 时已经被 funB 修改因此，当 funA 再次使用到 R 的数据已经是错误的数据了。如果 funA 在调用 funB 前保存寄存器 R 中的数据，funB 返回后再将数据恢复到 R 中，或者 funB 先保存 R 中原有的数据，然后在返回前恢复，就可以解决这类问题。唯一的调用约定那寄存器该由 caller 还是 callee 来保存？这就需要遵循函数的调用约定（call convention），不同的 ABI 和不同的平台，函数的调用约定是不一样的，对于 Linux 来说，它遵循的是 System V ABI 的 call convention，x86_64 平台下函数调用约定有且只有一种，调用者 caller 和被调用者 callee 需要对相应的寄存器进行保存和恢复操作：- Caller-save registers : RDI, RSI, RDX, RCX, R8, R9, RAX, R10, R11
- Callee-save registers : RBX, RBP, R12, R13, R14, R15
//test.c 文件//编译命令：gcc test.c -o test -O2 (kernel 采用的是 O2 优化选项)//执行过程：./test//输入参数：4
#include #include #include #include
#define noinline __attribute__ ((noinline)) //禁止内联
static noinline int c(int x){ return x * x * x;}
static noinline int b(int x){ return x;}
static noinline int newb(int x){ return c(x * 2) * x;}
static noinline int a(int x){ int volatile tmp = b(x); // tmp = 8 ** 3 * 4 return x tmp; // return 4(not 8) tmp}
int main(void){ int x; scanf("%d", 
下载文档
