libbpf/BPF-CORE kprobe arguments

libbpf/BPF-CORE kprobe arguments

[Bruno Dias da Gião]

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.

Again, sorry if there's clutter or if this message should not be sent
here.
-- 
Regards,
bdg

Re: libbpf/BPF-CORE kprobe arguments

[Andrii Nakryiko]

On Mon, Dec 11, 2023 at 3:18 PM Bruno Dias da Gião
<a96544@alunos.uminho.pt> 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
>