tracepoint/syscalls/sys_enter_execve missing args

[YTGhost]

I use cilium-ebpf to write some simple monitoring programs. Currently I want to use tracepoint/syscalls/sys_enter_execve to get argv. but I am having problems with missing arguments.

The following is an example of code that can be reproduced:

task.c

//go:build ignore

#include "common.h"
#include "bpf_helpers.h"

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

struct execve {
    __u64 unused;
    __u32 nr;
    const char *filename;
    const char *const *argv;
    const char *const *envp;
};

SEC("tracepoint/syscalls/sys_enter_execve")
int sys_enter_execve(struct execve *ctx) {
    for (int i = 0; i < 10; i++) {
        const char *arg = NULL;
        bpf_probe_read_user(&arg, sizeof(arg), &ctx->argv[i]);
        bpf_printk("arg%d: %s ", i, arg);
    }
    bpf_printk("\n");
    return 0;
}

main.go

package main

import (
    "github.com/cilium/ebpf/link"
    "github.com/cilium/ebpf/rlimit"
    "log"
    "time"
)

//go:generate go run github.com/cilium/ebpf/cmd/bpf2go bpf task.c -- -I../
func main() {

    // Allow the current process to lock memory for eBPF resources.
    if err := rlimit.RemoveMemlock(); err != nil {
        log.Fatal(err)
    }

    objs := bpfObjects{}
    if err := loadBpfObjects(&objs, nil); err != nil {
        log.Fatalf("loading objects: %v", err)
    }
    defer objs.Close()

    tpExecve, err := link.Tracepoint("syscalls", "sys_enter_execve", objs.SysEnterExecve, nil)
    if err != nil {
        log.Fatal(err)
    }
    defer tpExecve.Close()

    // Wait for signals.
    log.Printf("waiting for signals")

    // Read loop reporting the total amount of times the kernel
    // function was entered, once per second.
    ticker := time.NewTicker(2 * time.Second)
    defer ticker.Stop()

    for range ticker.C {
        log.Printf("tick \n")
    }
}

You can see that in task.c I tried to use tracepoint/syscalls/sys_enter_execve to get the argv and print them out.

After getting this ebpf program up and running, I will use ssh on another server to execute a script remotely. The command to be executed on the other server is shown below:

// hc is the server that run the ebpf program
ssh hc "see_app=be2e4d3d-2dad-4e48-a867-3006433f7e59;sh ./test.sh"

Ideally, the output of bpf_trace_printk should look like this:

sh-2127037 [001] d..31 763364.233432: bpf_trace_printk: arg0: bash
sh-2127037 [001] d..31 763364.233441: bpf_trace_printk: arg1: -c
sh-2127037 [001] d..31 763364.233448: bpf_trace_printk: arg2: see_app=be2e4d3d-2dad-4e48-a867-3006433f7e59;sh ./test.sh
sh-2127037 [001] d..31 763364.233460: bpf_trace_printk: arg3:
sh-2127037 [001] d..31 763364.233465: bpf_trace_printk: arg4:
sh-2127037 [001] d..31 763364.233469: bpf_trace_printk: arg5:
sh-2127037 [001] d..31 763364.233473: bpf_trace_printk: arg6:
sh-2127037 [001] d..31 763364.233477: bpf_trace_printk: arg7:
sh-2127037 [001] d..31 763364.233486: bpf_trace_printk: arg8:
sh-2127037 [001] d..31 763364.233495: bpf_trace_printk: arg9:
sh-2127037 [001] d..31 763364.233497: bpf_trace_printk:

But in sometime, the -c parameter is lost:

sh-2128777 [001] d..31 763441.999571: bpf_trace_printk: arg0: bash
sh-2128777 [001] d..31 763441.999582: bpf_trace_printk: arg1:
sh-2128777 [001] d..31 763441.999589: bpf_trace_printk: arg2: see_app=be2e4d3d-2dad-4e48-a867-3006433f7e59;sh ./test.sh
sh-2128777 [001] d..31 763441.999597: bpf_trace_printk: arg3:
sh-2128777 [001] d..31 763441.999600: bpf_trace_printk: arg4:
sh-2128777 [001] d..31 763441.999604: bpf_trace_printk: arg5:
sh-2128777 [001] d..31 763441.999607: bpf_trace_printk: arg6:
sh-2128777 [001] d..31 763441.999611: bpf_trace_printk: arg7:
sh-2128777 [001] d..31 763441.999618: bpf_trace_printk: arg8:
sh-2128777 [001] d..31 763441.999625: bpf_trace_printk: arg9:
sh-2128777 [001] d..31 763441.999626: bpf_trace_printk:

I also tried using kprobe/sys_execve, but I still have the problem of missing parameters. Has anyone ever encountered this problem and solved it?

[lmb]

Since you're seeing some arguments I'm guessing that this isn't a bug / problem in the library, but something specific to your BPF code. The discussions here are meant for help around the library, https://stackoverflow.com/questions/tagged/ebpf+or+bpf+or+xdp-bpf is a better bet for you.

That said, IIRC bpf_probe_read_user will return an error code. From https://man7.org/linux/man-pages/man7/bpf-helpers.7.html

       long bpf_probe_read_user(void *dst, u32 size, const void
       *unsafe_ptr)

              Description
                     Safely attempt to read size bytes from user space
                     address unsafe_ptr and store the data in dst.

              Return 0 on success, or a negative error in case of
                     failure.

I'd try inspecting the error code, and then following up on SO if your problem persists.

[YTGhost]

Thanks for your reply, in fact I already asked the question on stackoverflow last week: https://stackoverflow.com/questions/76438421/tracepoint-syscalls-sys-enter-execve-missing-args

I will also inspect the error code.

[YTGhost]

@lmb Hi, I try to print the error code, but I found that when -c is missing, the error code is still 0.
The code is as follows:

SEC("tracepoint/syscalls/sys_enter_execve")
int sys_enter_execve(struct execve *ctx) {
    for (int i = 0; i < 10; i++) {
        const char *arg = NULL;
        long num = bpf_probe_read_user(&arg, sizeof(arg), &ctx->argv[i]);
        bpf_printk("num: %ld, arg%d: %s ", num, i, arg);
    }
    bpf_printk("\n");
    return 0;
}

The output of bpf_printk is as follows:

sh-1795836 [001] d..31 1179970.314693: bpf_trace_printk: num: 0, arg0: bash
              sh-1795836 [001] d..31 1179970.314705: bpf_trace_printk: num: 0, arg1:
              sh-1795836 [001] d..31 1179970.314712: bpf_trace_printk: num: 0, arg2: see_app=be2e4d3d-2dad-4e48-a867-3006433f7e59;sh ./test.sh
              sh-1795836 [001] d..31 1179970.314722: bpf_trace_printk: num: 0, arg3:
              sh-1795836 [001] d..31 1179970.314727: bpf_trace_printk: num: 0, arg4:
              sh-1795836 [001] d..31 1179970.314731: bpf_trace_printk: num: 0, arg5:
              sh-1795836 [001] d..31 1179970.314736: bpf_trace_printk: num: 0, arg6:
              sh-1795836 [001] d..31 1179970.314741: bpf_trace_printk: num: 0, arg7:
              sh-1795836 [001] d..31 1179970.314749: bpf_trace_printk: num: 0, arg8:
              sh-1795836 [001] d..31 1179970.314758: bpf_trace_printk: num: 0, arg9:
              sh-1795836 [001] d..31 1179970.314759: bpf_trace_printk:

Is it possible that this is a problem or bug in the library?
More information about my system:

xieyun@xieyun-virtual-machine:~$ uname -a
Linux xieyun-virtual-machine 5.19.0-42-generic #43~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 21 16:51:08 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

[lmb]

That's always a possibility! The evidence so far isn't pointing in that direction however. Feel free to reach out if you find more evidence that it is a bug in the lib.