Add PROG_TEST_RUN support to BPF_PROG_TYPE_KPROBE

This commit adds PROG_TEST_RUN support to BPF_PROG_TYPE_KPROBE progs. On top of being generally useful for unit testing kprobe progs, this commit more specifically helps solve a relability problem with bpftrace BEGIN and END probes.

BEGIN and END probes are run exactly once at the beginning and end of a bpftrace tracing session, respectively. bpftrace currently implements the probes by creating two dummy functions and attaching the BEGIN and END progs, if defined, to those functions and calling the dummy functions as appropriate. This works pretty well most of the time except for when distros strip symbols from bpftrace. Every now and then this happens and users get confused. Having PROG_TEST_RUN support will help solve this issue by allowing us to directly trigger uprobes from userspace.

Admittedly, this is a pretty specific problem and could probably be solved other ways. However, PROG_TEST_RUN also makes unit testing more convenient, especially as users start building more complex tracing applications. So I see this as killing two birds with one stone.

Signed-off-by Daniel Xu <[email protected]>

---
 include/linux/bpf.h      | 10 ++++++++++
 kernel/trace/bpf_trace.c |  1 +
 net/bpf/test_run.c       | 36 ++++++++++++++++++++++++++++++++++++
 3 files changed, 47 insertions(+)

include/linux/bpf.h +3 -0

index 2b914a56a2c5..dec3082ee158 100644
@@ -1751,6 +1751,9 @@ int bpf_prog_test_run_raw_tp(struct bpf_prog *prog,
 int bpf_prog_test_run_sk_lookup(struct bpf_prog *prog,
                                const union bpf_attr *kattr,
                                union bpf_attr __user *uattr);
+int bpf_prog_test_run_kprobe(struct bpf_prog *prog,
+                            const union bpf_attr *kattr,
+                            union bpf_attr __user *uattr);
 bool btf_ctx_access(int off, int size, enum bpf_access_type type,
                    const struct bpf_prog *prog,
                    struct bpf_insn_access_aux *info);

include/linux/bpf.h +1 -0

+
 static inline void bpf_map_put(struct bpf_map *map)
 {
 }

kernel/trace/bpf_trace.c +1 -0

index 10b157a6d73e..b452e84b9ba4 100644
@@ -1363,6 +1363,7 @@ const struct bpf_verifier_ops kprobe_verifier_ops = {
 };
 
 const struct bpf_prog_ops kprobe_prog_ops = {
+       .test_run = bpf_prog_test_run_kprobe,
 };
 
 BPF_CALL_5(bpf_perf_event_output_tp, void *, tp_buff, struct bpf_map *, map,

net/bpf/test_run.c +36 -1

index 56f059b3c242..0b6fc17ce901 100644
@@ -1622,6 +1622,42 @@ int bpf_prog_test_run_syscall(struct bpf_prog *prog,
        return err;
 }
 
+int bpf_prog_test_run_kprobe(struct bpf_prog *prog,
+                            const union bpf_attr *kattr,
+                            union bpf_attr __user *uattr)
+{
+       void __user *ctx_in = u64_to_user_ptr(kattr->test.ctx_in);
+       __u32 ctx_size_in = kattr->test.ctx_size_in;
+       u32 repeat = kattr->test.repeat;
+       struct pt_regs *ctx = NULL;
+       u32 retval, duration;
+       int err = 0;
+
+       if (kattr->test.data_in || kattr->test.data_out ||
+           kattr->test.ctx_out || kattr->test.flags ||
+           kattr->test.cpu || kattr->test.batch_size)
+               return -EINVAL;
+
+       if (ctx_size_in != sizeof(struct pt_regs))
+               return -EINVAL;
+
+       ctx = memdup_user(ctx_in, ctx_size_in);
+       if (IS_ERR(ctx))
+               return PTR_ERR(ctx);
+
+       err = bpf_test_run(prog, ctx, repeat, &retval, &duration, false);
+       if (err)
+               goto out;
+
+       if (copy_to_user(&uattr->test.retval, &retval, sizeof(retval)) ||
+           copy_to_user(&uattr->test.duration, &duration, sizeof(duration))) {
+               err = -EFAULT;
+       }
+out:
+       kfree(ctx);
+       return err;
+}
+
 static const struct btf_kfunc_id_set bpf_prog_test_kfunc_set = {
        .owner        = THIS_MODULE,
        .check_set        = &test_sk_check_kfunc_ids,
--

2.36.1

This commit adds PROG_TEST_RUN support to BPF_PROG_TYPE_KPROBE progs. On top of being generally useful for unit testing kprobe progs, this commit more specifically helps solve a relability problem with bpftrace BEGIN and END probes.

BEGIN and END probes are run exactly once at the beginning and end of a bpftrace tracing session, respectively. bpftrace currently implements the probes by creating two dummy functions and attaching the BEGIN and END progs, if defined, to those functions and calling the dummy functions as appropriate. This works pretty well most of the time except for when distros strip symbols from bpftrace. Every now and then this happens and users get confused. Having PROG_TEST_RUN support will help solve this issue by allowing us to directly trigger uprobes from userspace.

Admittedly, this is a pretty specific problem and could probably be solved other ways. However, PROG_TEST_RUN also makes unit testing more convenient, especially as users start building more complex tracing applications. So I see this as killing two birds with one stone.

Quoted 16 lines · Daniel Xu

This commit adds PROG_TEST_RUN support to BPF_PROG_TYPE_KPROBE progs. On top of being generally useful for unit testing kprobe progs, this commit more specifically helps solve a relability problem with bpftrace BEGIN and END probes.

BEGIN and END probes are run exactly once at the beginning and end of a bpftrace tracing session, respectively. bpftrace currently implements the probes by creating two dummy functions and attaching the BEGIN and END progs, if defined, to those functions and calling the dummy functions as appropriate. This works pretty well most of the time except for when distros strip symbols from bpftrace. Every now and then this happens and users get confused. Having PROG_TEST_RUN support will help solve this issue by allowing us to directly trigger uprobes from userspace.

Quoted 4 lines

Admittedly, this is a pretty specific problem and could probably be solved other ways. However, PROG_TEST_RUN also makes unit testing more convenient, especially as users start building more complex tracing applications. So I see this as killing two birds with one stone.

bpftrace approach of uprobe-ing into BEGIN_trigger can be solved with raw_tp prog.
"BEGIN" bpftrace's program doesn't have to be uprobe. I can be raw_tp and prog_test_run command is already implemented for raw_tp.

kprobe prog has pt_regs as arguments,
raw_tp has tracepoint args.
Both progs expect kernel addresses in args.
Passing 'struct pt_regs' filled with integers and non-kernel addresses won't help to unit test bpf-kprobe programs.
There is little use in creating a dummy kprobe-bpf prog that expects RDI to be 1 and RSI to be 2
(like selftest from patch 2 does) and running it.

We already have raw_tp with similar args and such progs can be executed already.
Whether SEC() part says kprobe/ or raw_tp/ doesn't change much in the prog itself.

More so raw_tp prog will work on all architectures, whereas kprobe's pt_regs are arch specific.
So even if kprobe progs were runnable, bpftrace should probably be using raw_tp to be arch independent.

This commit adds a selftest to test that we can both PROG_TEST_RUN a kprobe prog and set its context.

Signed-off-by Daniel Xu <[email protected]>

---
 .../selftests/bpf/prog_tests/kprobe_ctx.c     | 57 +++++++++++++++++++
 .../testing/selftests/bpf/progs/kprobe_ctx.c  | 33 +++++++++++
 2 files changed, 90 insertions(+)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/kprobe_ctx.c
 create mode 100644 tools/testing/selftests/bpf/progs/kprobe_ctx.c

tools/testing/selftests/bpf/prog_tests/kprobe_ctx.c new file +57 -0

new file mode 100644
index 000000000000..260966fd4506
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <test_progs.h>
+#include <linux/ptrace.h>
+#include "kprobe_ctx.skel.h"
+
+/*
+ * x86_64 happens to be one of the architectures that exports the
+ * kernel `struct pt_regs` to userspace ABI. For the architectures
+ * that don't, users will have to extract `struct pt_regs` from vmlinux
+ * BTF in order to use BPF_PROG_TYPE_KPROBE's BPF_PROG_RUN functionality.
+ *
+ * We choose to only test x86 here to keep the test simple.
+ */
+void test_kprobe_ctx(void)
+{
+#ifdef __x86_64__
+       struct pt_regs regs = {
+               .rdi = 1,
+               .rsi = 2,
+               .rdx = 3,
+               .rcx = 4,
+               .r8 = 5,
+       };
+
+       LIBBPF_OPTS(bpf_test_run_opts, tattr,
+               .ctx_in = &regs,
+               .ctx_size_in = sizeof(regs),
+       );
+
+       struct kprobe_ctx *skel = NULL;
+       int prog_fd;
+       int err;
+
+       skel = kprobe_ctx__open_and_load();
+       if (!ASSERT_OK_PTR(skel, "skel_open"))
+               return;
+
+       skel->bss->expected_p1 = (void *)1;
+       skel->bss->expected_p2 = (void *)2;
+       skel->bss->expected_p3 = (void *)3;
+       skel->bss->expected_p4 = (void *)4;
+       skel->bss->expected_p5 = (void *)5;
+
+       prog_fd = bpf_program__fd(skel->progs.prog);
+       err = bpf_prog_test_run_opts(prog_fd, &tattr);
+       if (!ASSERT_OK(err, "bpf_prog_test_run"))
+               goto cleanup;
+
+       if (!ASSERT_TRUE(skel->bss->ret, "ret"))
+               goto cleanup;
+
+       if (!ASSERT_GT(tattr.duration, 0, "duration"))
+               goto cleanup;
+cleanup:
+       kprobe_ctx__destroy(skel);
+#endif
+}

tools/testing/selftests/bpf/progs/kprobe_ctx.c new file +33 -1

new file mode 100644
index 000000000000..98063c549930
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include "vmlinux.h"
+#include <bpf/bpf_helpers.h>
+#include <bpf/bpf_tracing.h>
+
+volatile void *expected_p1;
+volatile void *expected_p2;
+volatile void *expected_p3;
+volatile void *expected_p4;
+volatile void *expected_p5;
+volatile bool ret = false;
+
+SEC("kprobe/this_function_does_not_exist")
+int prog(struct pt_regs *ctx)
+{
+       void *p1, *p2, *p3, *p4, *p5;
+
+       p1 = (void *)PT_REGS_PARM1(ctx);
+       p2 = (void *)PT_REGS_PARM2(ctx);
+       p3 = (void *)PT_REGS_PARM3(ctx);
+       p4 = (void *)PT_REGS_PARM4(ctx);
+       p5 = (void *)PT_REGS_PARM5(ctx);
+
+       if (p1 != expected_p1 || p2 != expected_p2 || p3 != expected_p3 ||
+           p4 != expected_p4 || p5 != expected_p5)
+               return 0;
+
+       ret = true;
+       return 0;
+}
+
+char _license[] SEC("license") = "GPL";
--

2.36.1

This patchset adds PROG_TEST_RUN support to BPF_PROG_TYPE_KPROBE progs. On top of being generally useful for unit testing kprobe progs, this feature more specifically helps solve a relability problem with bpftrace BEGIN and END probes.

BEGIN and END probes are run exactly once at the beginning and end of a bpftrace tracing session, respectively. bpftrace currently implements the probes by creating two dummy functions and attaching the BEGIN and END progs, if defined, to those functions and calling the dummy functions as appropriate. This works pretty well most of the time except for when distros strip symbols from bpftrace. Every now and then this happens and users get confused. Having PROG_TEST_RUN support will help solve this issue by allowing us to directly trigger uprobes from userspace.

Admittedly, this is a pretty specific problem and could probably be solved other ways. However, PROG_TEST_RUN also makes unit testing more convenient, especially as users start building more complex tracing applications. So I see this as killing two birds with one stone.

Quoted 16 lines · Daniel Xu

This patchset adds PROG_TEST_RUN support to BPF_PROG_TYPE_KPROBE progs. On top of being generally useful for unit testing kprobe progs, this feature more specifically helps solve a relability problem with bpftrace BEGIN and END probes.

BEGIN and END probes are run exactly once at the beginning and end of a bpftrace tracing session, respectively. bpftrace currently implements the probes by creating two dummy functions and attaching the BEGIN and END progs, if defined, to those functions and calling the dummy functions as appropriate. This works pretty well most of the time except for when distros strip symbols from bpftrace. Every now and then this happens and users get confused. Having PROG_TEST_RUN support will help solve this issue by allowing us to directly trigger uprobes from userspace.

Quoted 4 lines

Admittedly, this is a pretty specific problem and could probably be solved other ways. However, PROG_TEST_RUN also makes unit testing more convenient, especially as users start building more complex tracing applications. So I see this as killing two birds with one stone.

We have BPF_PROG_RUN which is an alias of BPF_PROG_TEST_RUN. I guess that's a better name for the BEGIN/END use case.

Have you checked out bpf_prog_test_run_raw_tp()? AFAICT, it works as good as kprobe for this use case.

Hi Song,

Quoted 17 lines · Song Liu

Quoted 16 lines · Daniel Xu

This patchset adds PROG_TEST_RUN support to BPF_PROG_TYPE_KPROBE progs. On top of being generally useful for unit testing kprobe progs, this feature more specifically helps solve a relability problem with bpftrace BEGIN and END probes.

BEGIN and END probes are run exactly once at the beginning and end of a bpftrace tracing session, respectively. bpftrace currently implements the probes by creating two dummy functions and attaching the BEGIN and END progs, if defined, to those functions and calling the dummy functions as appropriate. This works pretty well most of the time except for when distros strip symbols from bpftrace. Every now and then this happens and users get confused. Having PROG_TEST_RUN support will help solve this issue by allowing us to directly trigger uprobes from userspace.

Quoted 7 lines

Quoted 4 lines

Admittedly, this is a pretty specific problem and could probably be solved other ways. However, PROG_TEST_RUN also makes unit testing more convenient, especially as users start building more complex tracing applications. So I see this as killing two birds with one stone.

We have BPF_PROG_RUN which is an alias of BPF_PROG_TEST_RUN. I guess that's a better name for the BEGIN/END use case.

Right, sorry. Was getting names mixed up.

Quoted 3 lines

Have you checked out bpf_prog_test_run_raw_tp()? AFAICT, it works as good as kprobe for this use case.

I just took a look -- I think it'll work for BEGIN/END use case. But also like I mentioned, BPF_PROG_RUN/BPF_PROG_TEST_RUN support for kprobes is probably still useful. For example if kprobe accesses 13th register. I suppose the raw_tp 12 arg limit could be lifted but it might be tricky to capture that logic in the absence of something like struct pt_regs to check the ctx_size_in against.