使用bpf_get_current_task_mount：获取mount分析文件系统挂载

在Linux系统中，进程看到的文件系统视图由挂载命名空间决定。容器技术通过为每个容器创建独立的命名空间来实现文件系统隔离，但这也带来了监管难题：一旦容器逃逸或误挂载宿主机的敏感目录，传统基于/proc文件系统的排查方式既慢又存在竞态窗口。eBPF技术提供了一种在内核实时采集挂载信息的能力，bpf_get_current_task_mount辅助函数可以直接获取当前任务所在命名空间的挂载点列表。本文将深入解析该函数的用法，并给出一个完整的监控案例。

bpf_get_current_task_mount辅助函数详解

bpf_get_current_task_mount是Linux内核为BPF程序提供的辅助函数，定义在include/uapi/linux/bpf.h中，原型如下：long bpf_get_current_task_mount(struct bpf_mount *mount, u32 size, u64 flags)。函数尝试将当前任务的挂载命名空间中的挂载点信息复制到用户提供的缓冲区中。mount参数指向一个struct bpf_mount类型的数组，size指定缓冲区总字节数，flags当前必须为零。返回值大于0表示成功填充的挂载点数量，负值表示错误码，例如-EFAULT表示缓冲区不可用，-ENOMEM表示缓冲区太小。

该结构体由内核定义，不同版本可能略有差异，但通常包含以下字段：mnt_id（挂载点唯一ID）、parent_mnt_id（父挂载点ID）、s_dev（底层块设备号）、mountpoint（挂载点路径）、fstype（文件系统类型）等。需要注意的是，缓冲区中的字符串字段以空字符结尾，但路径长度可能被截断，设计时需要考虑足够的缓冲区大小。实际开发时应直接包含内核头文件并使用原始定义，示例代码中为了演示会给出一个简化版本。

在内核源码中，该辅助函数最终调用namespace相关的遍历函数，从current->nsproxy->mnt_ns中获取挂载树，遍历每个vfsmount结构并提取信息。由于该操作直接访问内核数据结构，性能远高于用户态解析/proc/self/mountinfo，并且可以避免多次系统调用和文件读取的开销。这种在内核态完成数据采集的方式非常适合高频监控场景。

编写BPF程序采集挂载信息

为了演示bpf_get_current_task_mount的实际用法，我们编写一个eBPF程序，使用kprobe挂载到内核的do_mount函数。do_mount在每次挂载操作发生时被调用，我们可以在此时获取当前进程的完整挂载列表，从而捕获挂载变化事件。攻击者执行非法挂载时，这个位置能够第一时间感知到。

下面给出完整的BPF内核态代码。代码中首先定义了一个与内核struct bpf_mount兼容的结构体（实际开发时应直接包含内核头文件并使用原始定义），然后通过BPF_PERF_EVENT_ARRAY将采集到的事件发送到用户态。为了避免一次发送过多数据，我们只发送前8个挂载点作为示例。

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <linux/version.h>
#include <linux/sched.h>
#include <linux/mount.h>

#define MAX_MOUNTS 64
#define PATH_MAX 4096

struct bpf_mount_info {
    __u64 mnt_id;
    __u64 parent_mnt_id;
    __u64 s_dev;
    char mountpoint[PATH_MAX];
    char fstype[16];
};

struct event {
    __u32 pid;
    char comm[16];
    __u32 mount_count;
    struct bpf_mount_info mounts[8];
};

struct {
    __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
    __uint(key_size, sizeof(__u32));
    __uint(value_size, sizeof(__u32));
} events SEC(".maps");

SEC("kprobe/do_mount")
int kprobe_do_mount(struct pt_regs *ctx)
{
    struct bpf_mount_info mounts[MAX_MOUNTS];
    __u32 count = bpf_get_current_task_mount(mounts, sizeof(mounts), 0);
    if (count <= 0)
        return 0;

    struct event e = {};
    e.pid = bpf_get_current_pid_tgid() >> 32;
    bpf_get_current_comm(&e.comm, sizeof(e.comm));
    e.mount_count = count;
    __u32 n = count < 8 ? count : 8;
    for (int i = 0; i < n; i++) {
        e.mounts[i] = mounts[i];
    }
    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &e, sizeof(e));
    return 0;
}

char LICENSE[] SEC("license") = "GPL";

代码中bpf_get_current_task_mount的第一个参数是一个数组指针，第二个参数是整个数组字节大小，第三个参数为保留标志。如果返回值为正数，表示填充的挂载点个数；如果返回负数，则说明获取失败。我们使用bpf_perf_event_output将结构化事件提交给用户态，其中包含进程PID、进程名和部分挂载点信息。这样既避免了内核态日志打印的昂贵开销，又能够将数据批量传输给用户态做进一步分析。

用户态程序加载与数据解析

用户态程序主要负责加载编译好的BPF对象、等待perf buffer事件并解析打印。现代做法通常使用libbpf库来完成加载和事件订阅。下面是一个简化版的C程序框架，演示如何读取挂载点信息。该程序首先打开BPF对象文件，加载并挂载内核态程序，然后循环读取perf buffer，打印每个事件中的挂载点路径和文件系统类型。

#include <stdio.h>
#include <stdlib.h>
#include <bpf/libbpf.h>
#include <bpf/bpf.h>
#include <signal.h>
#include <unistd.h>
#include <errno.h>

struct bpf_mount_info {
    __u64 mnt_id;
    __u64 parent_mnt_id;
    __u64 s_dev;
    char mountpoint[4096];
    char fstype[16];
};

struct event {
    __u32 pid;
    char comm[16];
    __u32 mount_count;
    struct bpf_mount_info mounts[8];
};

static volatile bool running = true;

void handle_event(void *ctx, int cpu, void *data, __u32 data_sz)
{
    struct event *e = data;
    printf("PID %d (%s) mount_count=%u\n", e->pid, e->comm, e->mount_count);
    for (int i = 0; i < e->mount_count && i < 8; i++) {
        printf("  mnt_id=%llu parent=%llu dev=%llu path=%s fstype=%s\n",
               e->mounts[i].mnt_id,
               e->mounts[i].parent_mnt_id,
               e->mounts[i].s_dev,
               e->mounts[i].mountpoint,
               e->mounts[i].fstype);
    }
}

int main(int argc, char **argv)
{
    struct bpf_object *obj = NULL;
    struct bpf_program *prog = NULL;
    struct perf_buffer *pb = NULL;
    int err;

    obj = bpf_object__open("mount_monitor.bpf.o");
    if (!obj) {
        fprintf(stderr, "failed to open BPF object\n");
        return 1;
    }

    err = bpf_object__load(obj);
    if (err) {
        fprintf(stderr, "failed to load BPF object\n");
        goto cleanup;
    }

    prog = bpf_object__find_program_by_name(obj, "kprobe_do_mount");
    if (!prog) {
        fprintf(stderr, "failed to find program\n");
        goto cleanup;
    }

    err = bpf_program__attach(prog);
    if (err) {
        fprintf(stderr, "failed to attach program\n");
        goto cleanup;
    }

    pb = perf_buffer__new(bpf_object__find_map_fd_by_name(obj, "events"), 64,
                          handle_event, NULL, NULL, NULL);
    if (!pb) {
        fprintf(stderr, "failed to open perf buffer\n");
        goto cleanup;
    }

    while (running) {
        perf_buffer__poll(pb, 100);
    }

cleanup:
    perf_buffer__free(pb);
    bpf_object__close(obj);
    return 0;
}

解析到挂载点数据后，可以进一步做更复杂的分析，例如对比前后两次挂载点集合来发现新增或删除的挂载，或者根据挂载点路径判断是否属于可疑操作（如挂载/proc、/sys到容器内非标准位置）。用户态程序也可以将事件发送到集中式日志系统，实现长期审计和告警。

应用场景：容器挂载命名空间审计

容器安全监控是bpf_get_current_task_mount最典型的应用场景。攻击者在获得容器内权限后，可能会尝试挂载宿主机目录到容器内部，从而读写宿主机文件。通过eBPF在挂载系统调用处捕获挂载信息，安全系统能够实时发现这些异常操作。与依赖周期扫描/proc相比，这种基于事件的机制响应速度更快，且不易被绕过。

例如，可以设置规则：如果某个容器进程（通过cgroup判断）执行了挂载操作，并且挂载点指向宿主机特有的路径（如/var/run/docker.sock或/root/.ssh），则立即告警。bpf_get_current_task_mount返回的挂载点列表允许我们检查挂载目标的绝对路径，不需要额外解析/proc接口，也减少了用户态代码的复杂度。

另一个应用是跟踪挂载命名空间的传播。在多租户Kubernetes集群中，管理员可以通过该函数定期采集每个Pod的挂载点集合，生成基线，当出现偏离时触发审计。这种思路同样适用于检测容器逃逸后对宿主机文件系统的未授权访问，因为任何异常的挂载操作都会留下记录。

注意事项与兼容性问题

使用bpf_get_current_task_mount必须注意内核版本。该辅助函数在较新的内核中才被引入（大约5.17版本），因此部署前需要确认目标内核是否支持。可以通过bpftool feature probe查看辅助函数是否可用，或者在加载BPF程序时检查是否返回-EINVAL等错误。

权限方面，加载BPF程序通常需要root权限或CAP_BPF能力。此外，当挂载点数量极大时（例如宿主机上运行数千个容器），一次获取所有挂载信息可能占用较多内存和时间，建议在BPF程序中限制调用频率，或通过flags参数控制返回数据量（尽管当前flags只支持0）。在编写生产代码时，还应该考虑缓冲区大小与挂载点数量的动态匹配问题。

最后，不要在生产环境中直接使用示例代码，struct bpf_mount的定义可能因内核补丁而变化，务必以目标内核的实际头文件为准，并做好版本适配。同时，建议对获取到的挂载点数据进行过滤和限制，避免因单次输出过大而影响系统性能。

bpf_get_current_task_mounteBPF文件系统挂载修改时间：2026-09-25 20:14:22