在 Linux 内核中包装函数时遇到问题

Question

我编写了一个 LKM，可以在内核中实现可信路径执行 (TPE)：

https://github.com /cormander/tpe-lkm

当我将 WRAP_SYSCALLS 定义为 1 时，我偶尔会遇到内核 OOPS（在本问题末尾进行描述），并且我很聪明结束尝试追踪它。

一点背景知识：

由于 LSM 框架不导出其符号，因此我必须发挥创意，将 TPE 检查插入正在运行的内核中。我编写了一个 find_symbol_address() 函数，它可以为我提供所需的任何函数的地址，并且效果很好。我可以这样调用函数：

int (*my_printk)(const char *fmt, ...);
my_printk = find_symbol_address("printk");
(*my_printk)("Hello, world!\n");

它工作得很好。我使用此方法来查找 security_file_mmap、security_file_mprotect 和 security_bprm_check 函数。

然后，我使用 asm 跳转到我的函数来覆盖这些函数以进行 TPE 检查。问题是，当前加载的 LSM 将不再执行该函数的挂钩代码，因为它已被完全劫持。

下面是我所做的一个示例：

int tpe_security_bprm_check(struct linux_binprm *bprm) {

    int ret = 0;

    if (bprm->file) {
            ret = tpe_allow_file(bprm->file);
            if (IS_ERR(ret))
                    goto out;
    }

#if WRAP_SYSCALLS
    stop_my_code(&cs_security_bprm_check);

    ret = cs_security_bprm_check.ptr(bprm);

    start_my_code(&cs_security_bprm_check);
#endif

    out:

    return ret;
}

请注意 #if WRAP_SYSCALLS 部分之间的部分（默认情况下定义为 0）。如果设置为 1，则会调用 LSM 的钩子，因为我通过 asm 跳转写回原始代码并调用该函数，但我偶尔会遇到带有“无效操作码”的内核 OOPS：

invalid opcode: 0000 [#1] SMP 
RIP: 0010:[<ffffffff8117b006>]  [<ffffffff8117b006>] security_bprm_check+0x6/0x310

我不不知道是什么问题。我尝试了几种不同类型的锁定方法（有关详细信息，请参阅 start/stop_my_code 内部），但均无济于事。要触发内核 OOPS，请编写一个简单的 bash while 循环，该循环不断启动后台“ls”命令。大约一分钟后，它就会发生。

我正在 RHEL6 内核上测试它，也适用于 Ubuntu 10.04 LTS (2.6.32 x86_64)。

虽然这种方法是迄今为止最成功的，但我尝试了另一种方法，将内核函数简单地复制到我用 kmalloc 创建的指针，但是当我尝试执行它时，我得到：内核尝试执行 NX 保护的页面 - 漏洞利用尝试？ （uid：0）。如果有人可以告诉我如何 kmalloc 空间并将其标记为可执行文件，那也将帮助我解决上述问题。

任何帮助表示赞赏！

Answer 1

1.看来，security_bprm_check()的开头在函数调用之前没有完全恢复。哎呀发生在 security_bprm_check+0x6 处，即就在您放置在那里的跳​​转之后，所以看起来跳转的某些部分在那一刻仍然存在。我现在无法说出为什么会发生这种情况。

看看Kernel Probes (KProbes)在x86上的实现，它可能会给你一些提示。有关详细信息，另请参阅KProbes 说明。 KProbe 需要以安全的方式修补和恢复几乎任意的内核代码片段才能完成其工作。

2.现在谈谈您提到的另一种方法，即有关函数复制的方法。以下是一些 hack，内核开发人员会不赞成，但如果没有其他方法，这可能会有所帮助。

您可以分配内存以将函数复制到与分配内核模块代码的内存相同的区域。默认情况下该区域应该是可执行的。同样，KProbes 使用这个技巧来分配它们的绕行缓冲区。

内存由module_alloc()函数分配，并由module_free()释放。这些函数当然不会导出，但您可以按照与 security_file_mmap() 等相同的方式找到它们的地址。出于好奇，您正在使用 kallsyms_on_each_symbol()，对吧？

如果您以这种方式分配内存，这也可以帮助避免另一个不那么明显的问题。在 x86-64 上，可用于 kmalloc 和模块代码的内存地址区域彼此相距很远（请参阅 Documentation/x86/x86_64/mm.txt），超出任何相对跳转的范围。如果内存映射到模块的地址区域，则可以使用近相对跳转和调用来调用复制的函数。通过这种方式也可以避免 RIP 相对寻址的类似问题。

编辑：请注意，在 x86 上，如果您将某些代码复制到不同的内存区域并且希望它在那里运行，则可能需要对该代码进行一些更改。至少您需要修复将控制权转移到复制代码之外的相对调用和跳转（例如，对另一个函数的调用等）以及具有 RIP 相对寻址的指令。

除此之外，代码中可能还有其他结构需要修复。例如，编译器可能已将部分甚至全部 switch 语句优化为通过表进行跳转。也就是说，每个 case 的代码块的地址都保存在内存中的一个表中，而 switch 变量是该表的索引。这样，您的模块将执行类似 jmp(%reg, N) 的内容（N 是指针的大小，以字节为单位），而不是进行多次比较。也就是说，只是跳转到表中适当元素中的地址。由于此类表是在复制代码之前为代码创建的，因此可能需要进行修复，否则此类跳转会将执行带回原始代码而不是复制的代码。