On Mon, Dec 11, 2023 at 3:18 PM Bruno Dias da Gião
<a96544@xxxxxxxxxxxxxxxx> wrote:
>
> Hello,
> I read in one of Andrii Nakryiko's blogs that this was the best place to
> ask questions, sorry if not up to all standards.
>
> I have been working on some bcc -> libbpf conversions and have halted
> entirely when I reached working with kprobes.
>
> In the following code I attempt to pass to user space the parameters
> passed to the system call.
>
> SEC("kprobe/__x64_sys_openat")
> int BPF_KPROBE(kprobe__x64_sys_openat, int dfd, const char * path,
> int flags, unsigned short mode)
> {
> struct event *ev;
> ev = bpf_ringbuf_reserve(&rb, sizeof(*ev), 0);
> if (!ev) {
> return 1;
> }
> ev->pid = bpf_get_current_pid_tgid() >> 32;
> bpf_get_current_comm(&ev->comm, sizeof(ev->comm));
> ev->ts = bpf_ktime_get_ns();
> ev->dfd = dfd;
> ev->flags = flags;
> ev->mode = mode;
> bpf_probe_read_user_str(&ev->buffer,
> sizeof(ev->buffer),
> (void *)path);
> //bpf_printk("%d %d %s", ev->pid, ev->df, ev->buffer);
> bpf_ringbuf_submit(ev, 0);
> return 0;
> }
>
> However the output of this function (both printk and ringbuf) returns
> values that are either close to 2^32, for ev->df, or downright 0, for
> ev->buffer.
>
> Note that this works very cleanly when attaching instead with
> tracepoints but simply using tracepoints and not touching kprobes is not
> really an alternative for what I want.
>
> The result is also the same when using PT_REGS_PARM* or even explicit
> ctx->di/ctx->si (etc etc);
>
> So I wonder if the pt regs are actually being filled with wrong information,
> if I have an incorrect way of accessing the values of the registers.
> I did search online for information on these kinds of outputs but did
> not find any solutions.
Depending on kernel version and host architecture, parameters could be
stored in another pt_regs that is pointed to by the first argument.
You might want to google/grep for ARCH_HAS_SYSCALL_WRAPPER, if you are
interested.
But I'd recommend to just use BPF_KSYSCALL() macro in combination with
SEC("ksyscall/openat") program type, which abstracts all that away.
See [0] for a simple example.
Also, I heard that it might be best to use a per-syscall tracepoint
instead of kprobe, so you might want to experiment with that as well.
Tracepoints might be faster than kprobe, but I'd benchmark this first.
[0] https://github.com/libbpf/libbpf-bootstrap/blob/master/examples/c/ksyscall.bpf.c
>
> Again, sorry if there's clutter or if this message should not be sent
> here.
> --
> Regards,
> bdg
>
