Jprobe 不会监控所有的 `do_execve` 调用答案

【问题标题】：Jprobe doesn't monitor all `do_execve` callsJprobe 不会监控所有的 `do_execve` 调用
【发布时间】：2017-06-11 20:43:25
【问题描述】：

我知道过去有人对此提出过问题，但我没有找到解决方案。

我正在编写下一个内核模块来跟踪do_exec 调用。 AFAIK 每个新的进程映像（不是创建）都应该像这样加载，所以我想我可以用这个jprobe 追踪所有执行。

不幸的是，这个jprobe 的唯一输出是这些：

execve called /usr/lib/systemd/systemd-cgroups-agent by kworker/u8:3

我的模块代码如下：

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/kprobes.h>
#include <linux/fs.h>

static long jdo_execve(struct filename *filename, 
        const char __user *const __user __argv, 
        const char __user *const __user __envp)
{
    const char *name = filename->name;
    printk("execve called %s by %s\n", name, current->comm);
    jprobe_return();
    return 0;
}

static struct jprobe execve_jprobe = {
    .entry          = jdo_execve,
    .kp = {
        .symbol_name    = "do_execve",
    },
};

static int __init jprobe_init(void)
{
    int ret;

    ret = register_jprobe(&execve_jprobe);
    if (ret < 0) {
        printk(KERN_INFO "register_jprobe failed, returned %d\n", ret);
        return -1;
    }
    return 0;
}

static void __exit jprobe_exit(void)
{
    unregister_jprobe(&execve_jprobe);
    printk(KERN_INFO "jprobe at %p unregistered\n", write_jprobe.kp.addr);
}

module_init(jprobe_init)
module_exit(jprobe_exit)
MODULE_LICENSE("GPL");

我使用的是 CentOS 7，内核版本 3.10.0-514.el7.x86_64

感谢任何帮助！

【问题讨论】：

AFAIK every new process image (not creation) should be loaded like this - 例如，从 32 位环境执行的进程不使用此功能，它们使用 compat_do_execve。尝试钩住do_execve_common，这样你也会拦截32位进程的创建。
是的，当然，忘了说我正在运行一个 64 位内核，这个内核中没有 compat_do_execve 符号（请参阅帖子中的确切版本）
符号compat_do_execve（和其他“compat”符号）专门用于64位内核（是的，我注意到内核版本在您的帖子）当系统调用由 32 位应用程序 发出时。换句话说，你有 64 位内核，64 位操作系统，但它可以运行 32 位应用程序，它将使用“compat”系统调用。
不，在这个内核中没有compat_do_execve：[root@localhost 3.10.0-514.el7.x86_64]# grep -R do_execve * include/linux/sched.h:extern int do_execve(struct filename *, System.map:ffffffff81205ac0 t do_execve_common.isra.25 System.map:ffffffff81206150 T do_execve [root@localhost 3.10.0-514.el7.x86_64]# grep -R compat_do_execve * [root@localhost 3.10.0-514.el7.x86_64]#

标签： c linux-kernel jprobe

【解决方案1】：

手头的代码是：

SYSCALL_DEFINE3(execve,
                const char __user *, filename,
                const char __user *const __user *, argv,
                const char __user *const __user *, envp)
{
        return do_execve(getname(filename), argv, envp);
}

和：

int do_execve(struct filename *filename,
        const char __user *const __user *__argv,
        const char __user *const __user *__envp)
{
        struct user_arg_ptr argv = { .ptr.native = __argv };
        struct user_arg_ptr envp = { .ptr.native = __envp };
        return do_execve_common(filename, argv, envp);
}

考虑到该函数有多短，第一个明显的怀疑是它被内联到了 execve 入口点。拆机证实了怀疑：

0xffffffff811e6e20 <sys_execve>:        nopl   0x0(%rax,%rax,1) [FTRACE NOP]
0xffffffff811e6e25 <sys_execve+0x5>:    push   %rbp
0xffffffff811e6e26 <sys_execve+0x6>:    mov    %rsp,%rbp
0xffffffff811e6e29 <sys_execve+0x9>:    push   %r12
0xffffffff811e6e2b <sys_execve+0xb>:    mov    %rdx,%r12
0xffffffff811e6e2e <sys_execve+0xe>:    push   %rbx
0xffffffff811e6e2f <sys_execve+0xf>:    mov    %rsi,%rbx
0xffffffff811e6e32 <sys_execve+0x12>:   callq  0xffffffff811ef380 <getname>
0xffffffff811e6e37 <sys_execve+0x17>:   mov    %r12,%r8
0xffffffff811e6e3a <sys_execve+0x1a>:   mov    %rbx,%rdx
0xffffffff811e6e3d <sys_execve+0x1d>:   xor    %ecx,%ecx
0xffffffff811e6e3f <sys_execve+0x1f>:   xor    %esi,%esi
0xffffffff811e6e41 <sys_execve+0x21>:   mov    %rax,%rdi
0xffffffff811e6e44 <sys_execve+0x24>:   callq  0xffffffff811e6520 <do_execve_common>
0xffffffff811e6e49 <sys_execve+0x29>:   pop    %rbx
0xffffffff811e6e4a <sys_execve+0x2a>:   pop    %r12
0xffffffff811e6e4c <sys_execve+0x2c>:   cltq   
0xffffffff811e6e4e <sys_execve+0x2e>:   pop    %rbp
0xffffffff811e6e4f <sys_execve+0x2f>:   retq

因此，您没有看到大多数对 do_execve 的“调用”，因为在您感兴趣的代码路径中没有任何“调用”。

另一种调试方法是尝试对堆栈中更深或更高的东西进行探测。

我不得不问你为什么要玩 jprobes 或一般的内核。到目前为止，您似乎是一个初学者程序员，还不应该使用它。特别是，您不太可能编写遵守所有规则并能够解释其原因的内核代码（包括 jprobes）。创建在不充分的测试中似乎可以工作但被破坏的代码太容易了。

【讨论】：