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
