Hooking linux内核函数（三）：Ftrace的主要优缺点

本文是《Hooking Linux Kernel Functions, Part 3: What Are the Main Pros and Cons of Ftrace?》的翻译文章。

前言

Ftrace是一个Linux实例程序，通常用于跟踪内核函数。 但是，当我们寻找一个有用的解决方案，允许我们启用系统活动监控和阻止可疑进程时，发现Linux ftrace也可用于钩子函数调用。

这是本系列文章的最后一部分，本系列共分三部分，主要讨论如何使用ftrace来hook Linux内核函数。在本文中，我们将重点讨论ftrace的主要优缺点，并描述在用ftrace hooking Linux内核函数时所遇到的一些意外情况。阅读本系列文章的第一部分，了解其他四种可用于hooking Linux内核函数调用的方法。你在想:什么是ftrace?ftrace是如何工作的?那么请参阅本系列的第二部分，以获得这些问题的答案，并了解关于如何使用ftrace来hooking Linux内核函数。

使用ftrace的利弊

Ftrace使Linux内核函数更容易hook，并具有几个关键优势：

但就像我们在本系列中描述的其他方法一样，ftrace有一些缺点。

所有这些功能都可以在内核配置中禁用，因为它们对系统的运行并不重要。 但是，通常流行发行版使用的内核仍然包含所有这些内核选项，因为它们不会显着影响系统性能，并且可能对调试很有用。 但是，如果你需要支持某些特定的内核，最好还是记住这些要求。

让我们仔细分析这些缺点。

内核配置要求

内核必须同时支持ftrace和kallsyms。这需要启用两个配置选项:

接下来，ftrace必须支持动态寄存器修改，开启以下选项:

要访问FTRACE_OPS_FL_IPMODIFY标志，你使用的内核必须基于版本3.19或更高版本。旧的内核版本仍然可以修改%rip寄存器，但是在版本3.19中，只有在设置标志之后才能修改这个寄存器。在较老版本的内核中，出现此标志将导致编译错误。在较新的版本中，缺失这个标志意味着一个non-operating hook。

最后但并非最不重要的是，我们需要注意函数内部的ftrace调用位置。 ftrace调用必须位于函数的开头，在函数序言之前（形成堆栈帧并分配局部变量的空间）。 以下选项考虑了此功能：

虽然x86_64架构支持这个选项，但i386架构不支持。由于i386架构的ABI限制，编译器不能在函数序言之前插入ftrace调用。因此，当你执行ftrace调用时，函数堆栈已经被修改了，并且更改寄存器的值不足以hook函数。并且还需要撤消在序言中执行的操作，这些操作在不同的函数中有所不同。

这就是为什么ftrace函数hooking不支持32位x86体系结构。从理论上讲，你仍然可以通过生成和执行反序言来实现此方法，但是它将显著提高技术复杂性。

使用ftrace时的意外情况

在测试阶段，我们面临一个特殊的特性:在某些发行版上hook函数会导致系统永久挂起。当然，这个问题只发生在与开发人员使用的系统不同的系统上。我们也无法在任何发行版或内核版本上重现初始hooking原型的问题。

经调试，系统断在了钩子函数里。由于一些未知的原因，当在ftrace回调中调用原函数时，parent_ip仍然指向内核而不是函数包装器。这就启动了一个死循环，ftrace一遍又一遍地调用我们的包装器，而没有做任何有用的事情。

幸运的是，我们有错误的和有效的代码，最终发现了问题的原因。我们统一了代码并去掉了我们现在不需要的部分，并使包装器函数代码的两个版本之间的差异缩小了。

这是稳定的代码：

static asmlinkage long fh_sys_execve(const char __user *filename,
                const char __user *const __user *argv,
                const char __user *const __user *envp)
{
        long ret;

        pr_debug("execve() called: filename=%p argv=%p envp=%p\n",
                filename, argv, envp);

        ret = real_sys_execve(filename, argv, envp);

        pr_debug("execve() returns: %ld\n", ret);

        return ret;
}

这是导致系统挂起的代码:

static asmlinkage long fh_sys_execve(const char __user *filename,
                const char __user *const __user *argv,
                const char __user *const __user *envp)
{
        long ret;

        pr_devel("execve() called: filename=%p argv=%p envp=%p\n",
                filename, argv, envp);

        ret = real_sys_execve(filename, argv, envp);

        pr_devel("execve() returns: %ld\n", ret);

        return ret;
}

日志级别如何影响系统行为？ 令人惊讶的是，当我们仔细研究这两个函数的机器代码时，我们发现这些问题背后的原因是编译器。

结果是，pr_devel()调用被扩展为no-op。这个printk-macro版本用于开发阶段的日志记录。由于这些日志在操作阶段没有任何意义，系统会自动将它们从代码中删除，除非你激活了DEBUG宏。之后，编译器会看到这样的函数:

static asmlinkage long fh_sys_execve(const char __user *filename,
                const char __user *const __user *argv,
                const char __user *const __user *envp)
{
        return real_sys_execve(filename, argv, envp);
}

这就是优化的阶段。在我们的示例中，激活了所谓的尾部调用优化。如果一个函数调用另一个函数并立即返回它的值，这种优化让编译器可以用更直接的跳转到函数的主体来替换函数调用指令。这就是这个调用在机器代码中的样子:

0000000000000000 <fh_sys_execve>:
   0: e8 00 00 00 00 callq 5 <fh_sys_execve+0x5>
   5: ff 15 00 00 00 00 callq *0x0(%rip)
   b: f3 c3 repz retq </fh_sys_execve>

这是一个失败调用的例子：

0000000000000000 <fh_sys_execve>:
   0: e8 00 00 00 00 callq 5 <fh_sys_execve+0x5>
   5: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax
   c: ff e0 jmpq *%rax </fh_sys_execve>

第一个调用指令与编译器在所有函数的开头插入的fentry()调用完全相同。但在那之后，坏代码和稳定代码的行为就不同了。在稳定的代码中，我们可以看到调用指令执行的real_sys_execve调用(通过存储在内存中的指针)，在RET指令的帮助下，后面是fh_sys_execve()。然而，在坏代码中，直接跳转到JMP执行的real_sys_execve()函数。

尾部调用优化允许你通过不分配包含call指令存储在堆栈中的返回地址的无用堆栈帧来节省一些时间。但是，由于我们使用parent_ip来决定是否需要hook，因此返回地址的准确性对我们来说至关重要。经过优化后，fh_sys_execve()函数不再将新地址保存在堆栈中，因此只有旧地址指向内核。这就是为什么parent_ip一直指向内核内部，而那个死循环一开始就出现了。

这也是问题仅出现在某些发行版上的主要原因。 不同的发行版使用不同的编译标志集来编译模块。 在所有问题分布中，尾调用优化默认是开启的。

我们通过使用包装器函数关闭整个文件的尾部调用优化来解决这个问题:

# pragma GCC优化(“-fno-optimize-sibling-calls”)

至于进一步的hooking实验，你可以使用GitHub的完整内核模块代码。

结论

虽然开发人员通常使用ftrace来跟踪Linux内核函数调用，但这个实例程序本身对于Hooking Linux内核函数也非常有用。尽管这种方法有一些缺点，但它给了你一个关键的好处:代码和hook过程的整体简单性。

源链接

Hacking more

...