Can't trace sys_execve inside a c program

[godspeedcurry]

I write a C program to make system call, I want to use bpftrace to trace it. But when I use it, it can't print out the thing I want.
Here is the C program.

#include <stdio.h>
#include <unistd.h>
int main(){
    char * path = "/usr/bin/id";
    char *argv[] = {"/usr/bin/id","root", NULL};
    char* envp[] = { NULL };

    execve(path, argv, envp);
    return 0;
}

Left window command:

gcc test.c -o foo
./foo

Right window command:

bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%-6d %-8s", pid, comm); join(args->argv);}'

but when I use strace strace ./foo, everything works well. I got the line 14074 foo /usr/bin/id root

where is the problem?

[fbs]

Can you run with -kk? Its probably because the path isn't faulted into memory yet so the bpf read fails and you get an empty string

[godspeedcurry]

Hello, when run with '-kk', it give the following message, by the way, the test environment is in docker (on mac)

stdin:1:62-78: WARNING: Failed to probe_read_user_str: Bad address (-14)
tracepoint:syscalls:sys_enter_execve { printf("%s: ", comm); join(args->argv) }
                                                             ~~~~~~~~~~~~~~~~
stdin:1:62-78: WARNING: Failed to probe_read_user_str: Bad address (-14)
tracepoint:syscalls:sys_enter_execve { printf("%s: ", comm); join(args->argv) }

[fbs]

Can you try to loop over and printf your argv from your code and see if it works after?

[godspeedcurry]

Can you try to loop over and printf your argv from your code and see if it works after?

could you show me the code, I am a beginner in kernel.

[fbs]

It has nothing to do with the kernel, its your own C code

printf("%s %s\n", argv[0], argv[1]);

Should be enough

[godspeedcurry]

Hi, I found another problem, If I print something before, I can get the thing I want...

#include <stdio.h>
#include <unistd.h>
int main(){
    printf("test");
    char * path = "/usr/bin/id";
    char *argv[] = {"/usr/bin/id","root", NULL};
    char* envp[] = { NULL };

    execve(path, argv, envp);

    return 0;
}

[godspeedcurry]

I tried what you mentioned, also works very well, but I can't explain it.

[godspeedcurry]

also I found that if the binary is statically linked, the program compiled by the original source code works very well.

[ValdikSS]

This is by design. Read this
https://research.nccgroup.com/2021/08/06/some-musings-on-common-ebpf-linux-tracing-bugs/

[fbs]

@ValdikSS what part of that doc are you referring to?

Like I said earlier, the data you're using isn't in memory yet. These static strings are compiled in and are not actually faulted into memory until they're accessed. The access won't happen until its read, which is after your bpftrace probe ran. BPF won't pull the data in so you get an EFAULT/-14.

By printing the values or just a random print of a constant string you pull the small amount of data into memory (as it goes by page, not by var) and then it works

[ValdikSS]

@fbs,

what part of that doc are you referring to?

While race conditions when hooking syscalls via kprobes and tracepoints are troublesome, it turns out that userspace can flat out block eBPF from reading syscall inputs if they reside in MAP_SHARED pages. It is worth noting that such tomfoolery is somewhat limited as it only works against bpf_probe_read(|_user|_kern) calls made before a page is read by the kernel in a given syscall handler. As a result, a quick “fix” for tracers is to perform such reads when the syscall returns. However, such a “fix” would increase the feasibility of race condition abuse whenever the syscall implementation takes longer than the syscall context switch.

[viktormalik]

Looks like this is not a bpftrace bug. Can we close?