gpt4 book ai didi

c - Jprobe 不监控所有 `do_execve` 调用

转载 作者:行者123 更新时间:2023-11-30 16:44:27 34 4
gpt4 key购买 nike

我知道过去曾有人问过这个问题,但我没有找到解决方案。

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

不幸的是,这个jprobe的唯一输出是:

execve 由 kworker/u8:3 调用/usr/lib/systemd/systemd-cgroups-agent

我的模块代码如下:

#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

感谢任何帮助!

最佳答案

手头的代码是:

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)并能够解释其原因。创建在不充分的测试中似乎可以工作但实际上已损坏的代码太容易了。

关于c - Jprobe 不监控所有 `do_execve` 调用,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44488597/

34 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com