On Mon, Mar 10, 2025 at 10:43 AM Blaise Boscaccy
<bboscaccy@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Song Liu <song@xxxxxxxxxx> writes:
>
> > On Fri, Mar 7, 2025 at 5:33 PM Blaise Boscaccy
> > <bboscaccy@xxxxxxxxxxxxxxxxxxx> wrote:
> >>
> >> This test exercises the kernel flag added to security_bpf by
> >> effectively blocking light-skeletons from loading while allowing
> >> normal skeletons to function as-is. Since this should work with any
> >> arbitrary BPF program, an existing program from LSKELS_EXTRA was
> >> used as a test payload.
> >>
> >> Signed-off-by: Blaise Boscaccy <bboscaccy@xxxxxxxxxxxxxxxxxxx>
> >> ---
> >> .../selftests/bpf/prog_tests/kernel_flag.c | 43 +++++++++++++++++++
> >> .../selftests/bpf/progs/test_kernel_flag.c | 28 ++++++++++++
> >> 2 files changed, 71 insertions(+)
> >> create mode 100644 tools/testing/selftests/bpf/prog_tests/kernel_flag.c
> >> create mode 100644 tools/testing/selftests/bpf/progs/test_kernel_flag.c
> >>
> >> diff --git a/tools/testing/selftests/bpf/prog_tests/kernel_flag.c b/tools/testing/selftests/bpf/prog_tests/kernel_flag.c
> >> new file mode 100644
> >> index 0000000000000..479ad5de3737e
> >> --- /dev/null
> >> +++ b/tools/testing/selftests/bpf/prog_tests/kernel_flag.c
> >> @@ -0,0 +1,43 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/* Copyright (c) 2025 Microsoft */
> >> +#include <test_progs.h>
> >> +#include "kfunc_call_test.skel.h"
> >> +#include "kfunc_call_test.lskel.h"
> >> +#include "test_kernel_flag.skel.h"
> >> +
> >> +void test_kernel_flag(void)
> >> +{
> >> + struct test_kernel_flag *lsm_skel;
> >> + struct kfunc_call_test *skel = NULL;
> >> + struct kfunc_call_test_lskel *lskel = NULL;
> >> + int ret;
> >> +
> >> + lsm_skel = test_kernel_flag__open_and_load();
> >> + if (!ASSERT_OK_PTR(lsm_skel, "lsm_skel"))
> >> + return;
> >> +
> >> + ret = test_kernel_flag__attach(lsm_skel);
> >> + if (!ASSERT_OK(ret, "test_kernel_flag__attach"))
> >> + goto close_prog;
> >> +
> >> + lsm_skel->bss->monitored_pid = getpid();
> >
> > We usually set monitored_pid before attaching the program.
> >
>
> Okay, copy that.
>
> >> +
> >> + /* Test with skel. This should pass the gatekeeper */
> >> + skel = kfunc_call_test__open_and_load();
> >> + if (!ASSERT_OK_PTR(skel, "skel"))
> >> + goto close_prog;
> >> +
> >> + /* Test with lskel. This should fail due to blocking kernel-based bpf() invocations */
> >> + lskel = kfunc_call_test_lskel__open_and_load();
> >> + if (!ASSERT_ERR_PTR(lskel, "lskel"))
> >> + goto close_prog;
> >> +
> >> +close_prog:
> >> + if (skel)
> >> + kfunc_call_test__destroy(skel);
> >> + if (lskel)
> >> + kfunc_call_test_lskel__destroy(lskel);
> >> +
> >> + lsm_skel->bss->monitored_pid = 0;
> >> + test_kernel_flag__destroy(lsm_skel);
> >> +}
> >> diff --git a/tools/testing/selftests/bpf/progs/test_kernel_flag.c b/tools/testing/selftests/bpf/progs/test_kernel_flag.c
> >> new file mode 100644
> >> index 0000000000000..9ca01aadb6656
> >> --- /dev/null
> >> +++ b/tools/testing/selftests/bpf/progs/test_kernel_flag.c
> >> @@ -0,0 +1,28 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +
> >> +/*
> >> + * Copyright (C) 2025 Microsoft Corporation
> >> + *
> >> + * Author: Blaise Boscaccy <bboscaccy@xxxxxxxxxxxxxxxxxxx>
> >> + */
> >> +
> >> +#include "vmlinux.h"
> >> +#include <errno.h>
> >> +#include <bpf/bpf_helpers.h>
> >> +#include <bpf/bpf_tracing.h>
> >> +
> >> +char _license[] SEC("license") = "GPL";
> >> +
> >> +__u32 monitored_pid;
> >> +
> >> +SEC("lsm.s/bpf")
> >> +int BPF_PROG(bpf, int cmd, union bpf_attr *attr, unsigned int size, bool kernel)
> >> +{
> >> + __u32 pid;
> >> +
> >> + pid = bpf_get_current_pid_tgid() >> 32;
> >> + if (!kernel || pid != monitored_pid)
> >> + return 0;
> >
> > We are blocking lskel load for the pid. This could make
> > parallel testing (test_progs -j) flaky. We should probably
> > change the logic to filtering on monitored_tiid.
> >
>
> Curious on this for my own edification. The
>
> pid = bpf_get_current_pid_tgid() >> 32;
>
> is used extensively in the current test suite in a bunch of other
> tests. Why does that not cause an issue with the other tests during
> parallel testing?
We are blindly blocking all security_bpf() with kernel=true here, so
any lskel load in parallel with this test may fail. On the other hand,
existing tests only block some operations under certain conditions.
For example, test_cgroup1_hierarchy.c only blocks operations for
target_ancestor_cgid.
Does this make sense?
Thanks,
Song
