告别裸奔？用 eBPF 为你的 Linux 内核模块穿上安全盔甲！

作为一名整天和内核模块打交道的安全工程师，我太懂那种“战战兢兢，如履薄冰”的感觉了。辛辛苦苦写的模块，一不小心就可能被恶意篡改，甚至被“挂羊头卖狗肉”，想想就后怕！

所以，今天就跟大家聊聊如何用 eBPF 打造一个 Linux 内核模块的运行时安全监控系统，让你的模块不再“裸奔”，而是穿上安全盔甲！

为什么选择 eBPF？

可能有些小伙伴会问，内核安全监控方案那么多，为啥偏偏要用 eBPF 呢？

原因很简单：高效、灵活、安全！

• 高效：eBPF 程序运行在内核态，但又通过了严格的验证器，避免了像传统内核模块那样可能导致系统崩溃的风险。而且，eBPF 可以直接访问内核数据结构，无需额外的上下文切换，性能损失非常小。
• 灵活：eBPF 可以动态加载和卸载，无需重新编译内核。这意味着我们可以根据实际需求，随时调整监控策略，而无需重启系统。
• 安全：eBPF 程序在运行前会经过内核的验证器检查，确保程序的安全性，防止恶意代码注入。

我们要监控什么？

既然要搞安全监控，那肯定得先明确监控目标。对于内核模块来说，我认为以下几个方面是重点：

• 未授权的内存访问：防止模块访问不属于自己的内存区域，避免数据泄露或被篡改。
• 函数劫持：防止恶意模块通过修改函数指针等方式，劫持正常模块的执行流程。
• 恶意代码注入：防止恶意代码通过各种手段注入到模块中执行。
• 异常系统调用：监控模块是否发起了不正常的系统调用，例如尝试提升权限等。

如何用 eBPF 实现监控？

接下来，我们就来一步步看看如何用 eBPF 实现上述监控目标。

1. 监控内存访问

要监控内存访问，我们可以使用 eBPF 的 kprobe 功能，在模块的内存访问函数（例如 memcpy、memmove 等）入口处设置 hook 点。当这些函数被调用时，eBPF 程序会被触发，我们可以检查访问的内存地址是否在模块的合法范围内。

具体步骤如下：

• 定义 eBPF 程序：编写一个 eBPF 程序，用于检查内存访问的合法性。这个程序需要获取当前模块的起始地址和大小，然后判断访问的内存地址是否在这个范围内。
• 加载 eBPF 程序：使用 bpf() 系统调用加载 eBPF 程序到内核。
• 创建 kprobe：使用 perf_event_open() 系统调用创建 kprobe，将 eBPF 程序 hook 到 memcpy 等内存访问函数的入口处。

下面是一个简单的 eBPF 程序示例（使用 libbpf）：

// 定义 map，用于存储模块的起始地址和大小
BPF_HASH(module_info, pid_t, struct module_range);
 
struct module_range {
    u64 start;
    u64 end;
};
 
// kprobe 触发时执行的函数
int BPF_KPROBE(memcpy, void *dest, const void *src, size_t n) {
    pid_t pid = bpf_get_current_pid_tgid();
    struct module_range *range = module_info.lookup(&pid);
 
    if (!range) {
        // 没有找到模块信息，说明不是目标模块
        return 0;
    }
 
    u64 dest_addr = (u64)dest;
    u64 src_addr = (u64)src;
 
    // 检查目标地址是否在模块范围内
    if (dest_addr < range->start || dest_addr > range->end) {
        // 发现未授权的内存访问
        bpf_trace_printk("Unauthorized memory access to dest: 0x%llx\n", dest_addr);
    }
 
    // 检查源地址是否在模块范围内
    if (src_addr < range->start || src_addr > range->end) {
        // 发现未授权的内存访问
        bpf_trace_printk("Unauthorized memory access to src: 0x%llx\n", src_addr);
    }
 
    return 0;
}

2. 监控函数劫持

函数劫持是一种常见的攻击手段，攻击者通过修改函数指针等方式，将程序的执行流程导向恶意代码。为了防止函数劫持，我们可以监控模块中的函数指针是否被修改。

一种方法是使用 eBPF 的 tracepoint 功能，hook 到内核的 module_param tracepoint。当模块参数被修改时，这个 tracepoint 会被触发，我们可以检查被修改的参数是否是函数指针。

具体步骤如下：

• 定义 eBPF 程序：编写一个 eBPF 程序，用于检查被修改的参数是否是函数指针。这个程序需要获取被修改的参数的地址和大小，然后判断这个参数是否是函数指针。
• 加载 eBPF 程序：使用 bpf() 系统调用加载 eBPF 程序到内核。
• 创建 tracepoint：使用 perf_event_open() 系统调用创建 tracepoint，将 eBPF 程序 hook 到 module_param tracepoint。

另一种方法是直接监控模块中的 .data 段，因为函数指针通常存储在 .data 段中。我们可以使用 eBPF 的 kprobe 功能，hook 到 __kmod_putparams 函数的入口处。这个函数在模块加载时会被调用，用于初始化模块参数。我们可以在这个函数中获取模块的 .data 段的起始地址和大小，然后使用 bpf_probe_write_user 函数监控这个区域的内存写入操作。

3. 监控恶意代码注入

恶意代码注入是指攻击者通过各种手段，将恶意代码注入到程序的内存空间中执行。为了防止恶意代码注入，我们可以监控模块的 .text 段（代码段）是否被修改。

类似于监控函数劫持，我们可以使用 eBPF 的 kprobe 功能，hook 到 module_load 函数的入口处。这个函数在模块加载时会被调用，我们可以在这个函数中获取模块的 .text 段的起始地址和大小，然后使用 bpf_probe_write_user 函数监控这个区域的内存写入操作。

4. 监控异常系统调用

为了监控模块是否发起了不正常的系统调用，我们可以使用 eBPF 的 tracepoint 功能，hook 到 sys_enter 和 sys_exit tracepoint。当模块发起系统调用时，sys_enter tracepoint 会被触发，我们可以记录下系统调用的 ID 和参数。当系统调用返回时，sys_exit tracepoint 会被触发，我们可以检查系统调用的返回值是否正常。

具体步骤如下：

• 定义 eBPF 程序：编写一个 eBPF 程序，用于记录系统调用的 ID 和参数，并检查系统调用的返回值是否正常。
• 加载 eBPF 程序：使用 bpf() 系统调用加载 eBPF 程序到内核。
• 创建 tracepoint：使用 perf_event_open() 系统调用创建 tracepoint，将 eBPF 程序 hook 到 sys_enter 和 sys_exit tracepoint。

代码示例

下面是一个简单的 eBPF 程序示例，用于监控模块的系统调用：

// 定义 map，用于存储系统调用的信息
BPF_HASH(syscall_info, pid_t, struct syscall_data);
 
struct syscall_data {
    u64 id;
    u64 args[6];
};
 
// sys_enter tracepoint 触发时执行的函数
int BPF_TRACEPOINT(syscalls, sys_enter, pt_regs *regs, long id, long args[6]) {
    pid_t pid = bpf_get_current_pid_tgid();
    struct syscall_data data = {
        .id = id,
    };
    for (int i = 0; i < 6; i++) {
        data.args[i] = args[i];
    }
 
    syscall_info.update(&pid, &data);
    return 0;
}
 
// sys_exit tracepoint 触发时执行的函数
int BPF_TRACEPOINT(syscalls, sys_exit, pt_regs *regs, long ret) {
    pid_t pid = bpf_get_current_pid_tgid();
    struct syscall_data *data = syscall_info.lookup(&pid);
 
    if (!data) {
        // 没有找到系统调用信息，说明不是目标模块
        return 0;
    }
 
    // 检查系统调用的返回值是否正常
    if (ret < 0) {
        bpf_trace_printk("Syscall %lld failed with error: %ld\n", data->id, ret);
    }
 
    syscall_info.delete(&pid);
    return 0;
}

注意事项

• 性能影响：虽然 eBPF 的性能很高，但过多的监控点仍然会影响系统性能。因此，我们需要仔细选择监控目标，避免过度监控。
• 内核版本兼容性：不同的内核版本可能对 eBPF 的支持有所差异。我们需要根据实际情况，选择合适的 eBPF 功能和 API。
• 安全性：虽然 eBPF 程序经过了内核的验证器检查，但仍然存在一定的安全风险。我们需要仔细编写 eBPF 程序，避免出现漏洞。
• 动态性：内核模块的加载和卸载是动态的，因此我们需要动态地添加和删除 eBPF 监控点。

总结

通过 eBPF，我们可以构建一个强大的 Linux 内核模块运行时安全监控系统，有效地防止各种恶意攻击。虽然实现起来需要一定的技术门槛，但相信只要你认真学习，一定可以掌握这项技术，为你的内核模块保驾护航！

希望这篇文章能帮助你更好地理解 eBPF 在内核安全领域的应用。如果你有任何问题或建议，欢迎在评论区留言，一起交流学习！