On Tue, Aug 2, 2022 at 11:42 AM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Tue, Aug 2, 2022 at 9:21 AM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote:
> >
> > On Mon, Aug 1, 2022 at 2:44 PM Andrii Nakryiko
> > <andrii.nakryiko@xxxxxxxxx> wrote:
> > >
> > > On Mon, Aug 1, 2022 at 10:39 AM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote:
> > > >
> > > > Apparently, no existing selftest covers it. Add a new one where
> > > > we load cgroup/bind4 program and attach fentry to it.
> > > > Calling bpf_obj_get_info_by_fd on the fentry program
> > > > should return non-zero btf_id/btf_obj_id instead of crashing the kernel.
> > > >
> > > > v2:
> > > > - use ret instead of err in find_prog_btf_id (Hao)
> > > > - remove verifier log (Hao)
> > > > - drop if conditional from ASSERT_OK(bpf_obj_get_info_by_fd(...)) (Hao)
> > > >
> > > > Signed-off-by: Stanislav Fomichev <sdf@xxxxxxxxxx>
> > > > ---
> > > > .../selftests/bpf/prog_tests/attach_to_bpf.c | 97 +++++++++++++++++++
> > > > .../selftests/bpf/progs/attach_to_bpf.c | 12 +++
> > > > 2 files changed, 109 insertions(+)
> > > > create mode 100644 tools/testing/selftests/bpf/prog_tests/attach_to_bpf.c
> > > > create mode 100644 tools/testing/selftests/bpf/progs/attach_to_bpf.c
> > > >
> > >
> > > [...]
> > >
> > > > +
> > > > + ret = btf__find_by_name_kind(btf, name, BTF_KIND_FUNC);
> > > > + btf__free(btf);
> > > > + return ret;
> > > > +}
> > > > +
> > > > +int load_fentry(int attach_prog_fd, int attach_btf_id)
> > >
> > > static?
> > >
> > > > +{
> > > > + LIBBPF_OPTS(bpf_prog_load_opts, opts,
> > > > + .expected_attach_type = BPF_TRACE_FENTRY,
> > > > + .attach_prog_fd = attach_prog_fd,
> > > > + .attach_btf_id = attach_btf_id,
> > > > + );
> > > > + struct bpf_insn insns[] = {
> > > > + BPF_MOV64_IMM(BPF_REG_0, 0),
> > > > + BPF_EXIT_INSN(),
> > > > + };
> > > > +
> > > > + return bpf_prog_load(BPF_PROG_TYPE_TRACING,
> > > > + "bind4_fentry",
> > > > + "GPL",
> > > > + insns,
> > > > + ARRAY_SIZE(insns),
> > > > + &opts);
> > > > +}
> > > > +
> > > > +void test_attach_to_bpf(void)
> > > > +{
> > > > + struct attach_to_bpf *skel = NULL;
> > > > + struct bpf_prog_info info = {};
> > > > + __u32 info_len = sizeof(info);
> > > > + int cgroup_fd = -1;
> > > > + int fentry_fd = -1;
> > > > + int btf_id;
> > > > +
> > > > + cgroup_fd = test__join_cgroup("/attach_to_bpf");
> > > > + if (!ASSERT_GE(cgroup_fd, 0, "cgroup_fd"))
> > > > + return;
> > > > +
> > > > + skel = attach_to_bpf__open_and_load();
> > > > + if (!ASSERT_OK_PTR(skel, "skel"))
> > > > + goto cleanup;
> > > > +
> > > > + skel->links.bind4 = bpf_program__attach_cgroup(skel->progs.bind4, cgroup_fd);
> > > > + if (!ASSERT_OK_PTR(skel, "bpf_program__attach_cgroup"))
> > >
> > > you probably meant to check skel->links.bind4 instead of just skel
> > > (which you already checked)
> >
> > Oh, good catch, thanks!
> >
> > > > + goto cleanup;
> > > > +
> > > > + btf_id = find_prog_btf_id("bind4", bpf_program__fd(skel->progs.bind4));
> > > > + if (!ASSERT_GE(btf_id, 0, "find_prog_btf_id"))
> > > > + goto cleanup;
> > > > +
> > > > + fentry_fd = load_fentry(bpf_program__fd(skel->progs.bind4), btf_id);
> > > > + if (!ASSERT_GE(fentry_fd, 0, "load_fentry"))
> > > > + goto cleanup;
> > > > +
> > > > + /* Make sure bpf_obj_get_info_by_fd works correctly when attaching
> > > > + * to another BPF program.
> > > > + */
> > > > +
> > > > + ASSERT_OK(bpf_obj_get_info_by_fd(fentry_fd, &info, &info_len),
> > > > + "bpf_obj_get_info_by_fd");
> > > > +
> > > > + ASSERT_EQ(info.btf_id, 0, "info.btf_id");
> > > > + ASSERT_GT(info.attach_btf_id, 0, "info.attach_btf_id");
> > > > + ASSERT_GT(info.attach_btf_obj_id, 0, "info.attach_btf_obj_id");
> > > > +
> > > > +cleanup:
> > >
> > > if (cgroup_fd >= 0)
> > >
> > > > + close(cgroup_fd);
> > >
> > > if (fentry_fd >= 0)
> >
> > Should be safe to do unconditional close(-1), right? Why bother with
> > the checks here? Seems like a common pattern we do elsewhere?
> >
>
> I don't think we consciously do close(-1), libbpf definitely tries
> hard to not attempt to close invalid fd, and so do (most?) of
> selftests. Where do you see use doing close(-1)?
I might have contributed to this :-/ Everything is from prog_tests:
sockopt_multi.c (test_sockopt_multi)
lsm_cgroup.c (test_lsm_cgroup_functional)
But there is more that haven't been added by me:
d_path.c (trigger_fstat_events)
cgroup_attach_override.c (serial_test_cgroup_attach_override)
cg_storage_multi.c (connect_send)
test_local_storage.c (test_test_local_storage)
bpf_cookie.c (kprobe_multi_link_api_subtest)
fexit_bpf2bpf.c (test_fentry_to_cgroup_bpf)
(I stopped here, maybe there is more?)
I'm not sure how much we should care about these 'if (fd >= 0)' checks.
It might be it's easier to always do close(-1), otherwise we get bugs
like the one in test_unpriv_bpf_disabled_positive from
unpriv_bpf_disabled.c:
if (link_fd)
close(link_fd);
(but I'm also happy to add those 'ifs' if you prefer, lmk)
?
> > > > + close(fentry_fd);
> > > > + attach_to_bpf__destroy(skel);
> > > > +}
> > > > diff --git a/tools/testing/selftests/bpf/progs/attach_to_bpf.c b/tools/testing/selftests/bpf/progs/attach_to_bpf.c
> > > > new file mode 100644
> > > > index 000000000000..3f111fe96f8f
> > > > --- /dev/null
> > > > +++ b/tools/testing/selftests/bpf/progs/attach_to_bpf.c
> > > > @@ -0,0 +1,12 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +
> > > > +#include <linux/bpf.h>
> > > > +#include <bpf/bpf_helpers.h>
> > > > +
> > > > +SEC("cgroup/bind4")
> > > > +int bind4(struct bpf_sock_addr *ctx)
> > > > +{
> > > > + return 1;
> > > > +}
> > > > +
> > > > +char _license[] SEC("license") = "GPL";
> > > > --
> > > > 2.37.1.455.g008518b4e5-goog
> > > >
