La macro BPF_KPROBE proporciona un valor inesperado del argumento de la llamada al sistema.

Mientras juego con libbpf-bootstrap, obtengo argumentos de función inesperados (y extraños) para las llamadas al sistema de kprobe. Por ejemplo, para la kprobe en la llamada al sistema “close” con la firma “int close(int fd)”, obtengo valores enormes de “fd” como “fd=15761240” en lugar del pequeño entero esperado “fd=4”. Reproduje esto en “Debian 11 x64 (kernel 5.10.0-7-amd64)” y “Ubuntu 21.10 x64 (kernel ~5.13)”.

Código de depuración:

include "vmlinux.h"

include <bpf bpf_helpers.h="">

include <bpf bpf_tracing.h="">

include <bpf bpf_core_read.h="">

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

// accept4 syscall
// int accept4(int sockfd, struct sockaddr *restrict addr, socklen_t *restrict addrlen);
SEC("kretprobe/x64/sys_accept4")
int BPF_KRETPROBE(accept, int ret) {
    u64 id = bpf_get_current_pid_tgid();
    u32 pid = id >> 32;

    // filter specific pid for simplicity
    if (pid != 31114 || ret < 0) {
        return 0;
    }

    // debug returned file descriptor
    bpf_printk("opened pid=%d fd=%d", pid, ret);
    return 0;
}

// close syscall
// int close(int fd);
SEC("kprobe/_x64/sys_close")
int BPF_KPROBE(close, int fd) {
    u64 id = bpf_get_current_pid_tgid();
    u32 pid = id >> 32;
    // filter specific pid for simplicity
    if (pid != 31114) {
        return 0;
    }

    // debug fd arg (expected to be equal to fd returned on accept4)
    bpf_printk("closed pid=%d fd=%d", pid, fd);
    return 0;
}

Resultados (ver la diferencia inesperada en “fd=4” frente a “fd=15761240”):

$ cat /sys/kernel/debug/tracing/trace_pipe
            main-31114   [001] d...  9069.254408: bpf_trace_printk: opened pid=31114 fd=4
            main-31114   [001] d...  9069.321946: bpf_trace_printk: closed pid=31114 fd=15761240

Intenté alterar “vmlinux.h”: primero con el “vmlinux.h” entregado por libbbpf-bootstrap y luego con el “vmlinux.h” “nativo” del kernel de la instancia del sistema operativo, y en ambas formas tuve el problema mencionado anteriormente.

También intenté ejecutar el mismo programa BPF de la manera de BCC (compilado con bcc en tiempo de ejecución) con kprobes declarados sin la macro BPF_KPROBE, así:

int syscall__probe_close_entry(struct pt_regs *ctx, int fd) { ... }

y funcionó como se esperaba: “fd=4” en todos los puntos de depuración.
¿Es un error/incompatibilidad de la macro BPF_KPROBE con el kernel o me estoy perdiendo algo?