Re: [PATCH bpf-next 6/7] selftests/bpf: Add tests for the generic netlink BPF hook

[Anton Protopopov <a.s.protopopov@gmail.com>]

On 26/08/31 12:07PM, bot+bpf-ci@kernel.org wrote:
> > Add a few tests for the new generic netlink BPF hook.
> > Policies only apply themselves to the "nlctrl" family.
> > The following tests are being added:
> >   * doit: allow or deny CTRL_CMD_GETFAMILY
> >   * dump: allow or deny CTRL_CMD_GETPOLICY, nlmsg_flags |= NLM_F_DUMP
> >   * nlmsg_flags: allow or deny a command based on nlmsg_flags
> >   * other_family: check that other families still pass
> 
> The enumeration lists four subtests but the patch registers five. The
> "netns" subtest is missing from this list:
> 
>     if (test__start_subtest("doit"))          test_doit(skel, fd);
>     if (test__start_subtest("dump"))          test_dump(skel, fd);
>     if (test__start_subtest("nlmsg_flags"))   test_nlmsg_flags(skel, fd);
>     if (test__start_subtest("other_family"))  test_other_family(skel, fd, other_id);
>     if (test__start_subtest("netns"))         test_netns(skel, fd);
> 
> The netns subtest is the only one exercising the net argument of
> bpf_lsm_genl_family_rcv_msg(), and it introduces target_netns_inum plus
> a filter in the BPF program, netns_new()/open_netns(), a second socket,
> and the netns_inum() helper - roughly 45 of the 242 added lines. Since
> the netns filtering path is the least obvious part of the hook contract,
> would it make sense to add a fifth bullet, for example "* netns: deny a
> command only inside a target netns, allow it elsewhere"?

Sure, thanks, will add. It was added later than first four.

> > diff --git a/tools/testing/selftests/bpf/config b/tools/testing/selftests/bpf/config
> > index 08c6e8a4e..6ca0b083a 100644
> > --- a/tools/testing/selftests/bpf/config
> > +++ b/tools/testing/selftests/bpf/config
> > @@ -30,6 +30,7 @@ CONFIG_DYNAMIC_FTRACE=y
> >  CONFIG_FPROBE=y
> >  CONFIG_FUNCTION_TRACER=y
> 
> [ ... ]
> 
> > diff --git a/tools/testing/selftests/bpf/prog_tests/genl_lsm.c b/tools/testing/selftests/bpf/prog_tests/genl_lsm.c
> > new file mode 100644
> > index 000000000..9f866c4c6
> > --- /dev/null
> > +++ b/tools/testing/selftests/bpf/prog_tests/genl_lsm.c
> 
> [ ... ]
> 
> > +static void test_nlmsg_flags(struct genl_lsm *skel, int fd)
> > +{
> > +	int err;
> > +
> > +	/* ensure denying works */
> > +	skel->bss->target_cmd = CTRL_CMD_GETFAMILY;
> > +	skel->bss->target_flags = NLM_F_REQUEST | NLM_F_DUMP;
> > +	skel->bss->allow = false;
> > +
> > +	err = nlctrl_request(fd, CTRL_CMD_GETFAMILY, false);
> > +	ASSERT_OK(err, "doit_flags_not_matched");
> > +
> > +	err = nlctrl_request(fd, CTRL_CMD_GETFAMILY, true);
> > +	ASSERT_EQ(err, -TEST_ERRNO, "deny_dump_flags");
> > +
> > +	/* now, the other way around */
> > +	skel->bss->target_flags = NLM_F_REQUEST;
> > +
> > +	err = nlctrl_request(fd, CTRL_CMD_GETFAMILY, true);
> > +	ASSERT_OK(err, "doit_flags_not_matched");
> > +
> > +	err = nlctrl_request(fd, CTRL_CMD_GETFAMILY, false);
> > +	ASSERT_EQ(err, -TEST_ERRNO, "deny_dump_flags");
> > +}
> 
> The second half reuses the assertion tags from the first half, but they
> name the opposite case. The dump request gets "doit_flags_not_matched"
> and the doit request gets "deny_dump_flags". The test logic is correct
> but when test_progs prints only the tag and __func__, a CI failure
> reporting "genl_lsm:FAIL:deny_dump_flags" cannot be attributed to either
> of the two assertions with that name, and whichever one it is, the tag
> names the wrong netlink operation. Would four distinct tags - for example
> "deny_dump_flags_matched", "allow_doit_flags_unmatched",
> "allow_dump_flags_unmatched", "deny_doit_flags_matched" - remove the
> ambiguity?

Yes, thanks.

> [ ... ]
> 
> > +void test_genl_lsm(void)
> > +{
> > +	struct genl_lsm *skel = NULL;
> > +	int fd = -1;
> > +	int err, other_id;
> > +
> > +	skel = genl_lsm__open_and_load();
> > +	if (!ASSERT_OK_PTR(skel, "genl_lsm__open_and_load"))
> > +		return;
> > +
> > +	fd = genl_open(0);
> > +	if (!ASSERT_OK_FD(fd, "genl_open"))
> > +		goto cleanup;
> > +
> > +	/* do this before attaching our hook, just in case */
> > +	other_id = genl_resolve_family(fd, OTHER_FAMILY_NAME);
> > +	if (other_id == -ENOENT) {
> > +		test__skip();
> > +		goto cleanup;
> > +	}
> 
> A subsystem pattern flags this as potentially concerning: when
> CONFIG_ETHTOOL_NETLINK is absent, genl_resolve_family() returns -ENOENT
> and the test skips with no printed reason. A reader of the TAP output
> sees "#N genl_lsm:SKIP" with nothing indicating the missing prerequisite
> was the ethtool genl family, so a silently-skipped test looks identical
> to a deliberately-disabled one. All five subtests are skipped this way,
> including the four (doit, dump, nlmsg_flags, netns) that do not need
> ethtool - only test_other_family() consumes other_id.
> 
> This pattern is common in bpf selftests (e.g. aggregate_ret.c:52,
> arena_spin_lock.c:57 and :66 all do exactly this), and the config hunk
> in this same patch adds CONFIG_ETHTOOL_NETLINK so the skip path should
> not be taken in a properly configured CI run. Would a one-line printf
> plus optionally deferring the ethtool resolution into test_other_family()
> so the other four subtests still run be worth addressing?

In fact, this is probably better to omit this check.
I've tried to do the same for CONFIG_SECURITY=n, but then figured out
that selftests won't even build for this case (not due to this patch).
So given I add ETHOOL, it's ok to expect that it is on.

> 
> [ ... ]
> 
> > diff --git a/tools/testing/selftests/bpf/progs/genl_lsm.c b/tools/testing/selftests/bpf/progs/genl_lsm.c
> > new file mode 100644
> > index 000000000..c4d8b4d23
> > --- /dev/null
> > +++ b/tools/testing/selftests/bpf/progs/genl_lsm.c
> 
> [ ... ]
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33386073074