Re: [PATCH bpf 2/2] selftests/bpf: add regression test for bpf_d_path()

[Matt Bobrowski <mattbobrowski@google.com>]

On Mon, Dec 01, 2025 at 10:38:13PM +0800, Shuran Liu wrote:
> Add a simple LSM BPF program and a corresponding test_progs test case
> to exercise bpf_d_path() and ensure that prefix comparisons on the
> returned path keep working.
> 
n> The LSM program hooks bprm_check_security, calls bpf_d_path() on the
> binary being executed, and compares the returned path against the
> "/tmp/" prefix. The result is recorded in an array map.
> 
> The user space test runs /tmp/bpf_d_path_test (copied from /bin/true)
> and checks that the BPF program records a successful prefix match.
> 
> Without the preceding fix to bpf_d_path()'s helper prototype, the
> test can fail due to the verifier incorrectly assuming that the
> buffer contents are unchanged across the helper call and misoptimizing
> the program. With the fix applied, the test passes.
> 
> Co-developed-by: Zesen Liu <ftyg@live.com>
> Signed-off-by: Zesen Liu <ftyg@live.com>
> Co-developed-by: Peili Gao <gplhust955@gmail.com>
> Signed-off-by: Peili Gao <gplhust955@gmail.com>
> Co-developed-by: Haoran Ni <haoran.ni.cs@gmail.com>
> Signed-off-by: Haoran Ni <haoran.ni.cs@gmail.com>
> Signed-off-by: Shuran Liu <electronlsr@gmail.com>
> ---
>  .../selftests/bpf/prog_tests/d_path_lsm.c     | 27 ++++++++++++
>  .../selftests/bpf/progs/d_path_lsm.bpf.c      | 43 +++++++++++++++++++
>  2 files changed, 70 insertions(+)
>  create mode 100644 tools/testing/selftests/bpf/prog_tests/d_path_lsm.c
>  create mode 100644 tools/testing/selftests/bpf/progs/d_path_lsm.bpf.c
> 
> diff --git a/tools/testing/selftests/bpf/prog_tests/d_path_lsm.c b/tools/testing/selftests/bpf/prog_tests/d_path_lsm.c
> new file mode 100644
> index 000000000000..92aad744ed12
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/d_path_lsm.c

I don't see why adding yet another new bpf_d_path() related test to
prog_tests is warranted here. Why not simply incorporate this
additional test case into the preexisting bpf_d_path() related
prog_tests source file i.e. tools/testing/selftests/bpf/d_path.c?

> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include <test_progs.h>
> +#include "d_path_lsm.skel.h"
> +
> +void test_d_path_lsm(void)
> +{
> +	struct d_path_lsm *skel = NULL;
> +	int err, map_fd, key = 0, val = 0;
> +
> +	skel = d_path_lsm__open_and_load();
> +	if (!ASSERT_OK_PTR(skel, "open_and_load"))
> +		return;
> +
> +	err = d_path_lsm__attach(skel);
> +	if (!ASSERT_OK(err, "attach"))
> +		goto out;
> +
> +	system("cp /bin/true /tmp/bpf_d_path_test 2>/dev/null || :");
> +	system("/tmp/bpf_d_path_test >/dev/null 2>&1");
> +
> +	map_fd = bpf_map__fd(skel->maps.result);
> +	err = bpf_map_lookup_elem(map_fd, &key, &val);
> +	ASSERT_OK(err, "lookup_result");
> +	ASSERT_EQ(val, 1, "prefix_match");
> +out:
> +	d_path_lsm__destroy(skel);
> +}
>
> diff --git a/tools/testing/selftests/bpf/progs/d_path_lsm.bpf.c b/tools/testing/selftests/bpf/progs/d_path_lsm.bpf.c
> new file mode 100644
> index 000000000000..36f9ff37e817
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/d_path_lsm.bpf.c
> @@ -0,0 +1,43 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include "vmlinux.h"
> +#include <bpf/bpf_helpers.h>
> +#include <bpf/bpf_tracing.h>
> +
> +char LICENSE[] SEC("license") = "GPL";
> +
> +#define FILENAME_MAX_SIZE 256
> +#define TARGET_DIR "/tmp/"
> +#define TARGET_DIR_LEN 5
> +
> +struct {
> +	__uint(type, BPF_MAP_TYPE_ARRAY);
> +	__uint(max_entries, 1);
> +	__type(key, int);
> +	__type(value, int);
> +} result SEC(".maps");
> +
> +SEC("lsm/bprm_check_security")
> +int BPF_PROG(d_path_lsm_prog, struct linux_binprm *bprm)
> +{
> +	char path[FILENAME_MAX_SIZE] = {};
> +	long len;
> +	int key = 0;
> +	int val = 0;
> +
> +	len = bpf_d_path(&bprm->file->f_path, path, sizeof(path));
> +	if (len < 0)
> +		return 0;
> +
> +#pragma unroll
> +	for (int i = 0; i < TARGET_DIR_LEN; i++) {
> +		if ((u8)path[i] != (u8)TARGET_DIR[i]) {
> +			val = -1; /* mismatch */
> +			bpf_map_update_elem(&result, &key, &val, BPF_ANY);
> +			return 0;
> +		}
> +	}
> +
> +	val = 1; /* prefix match */
> +	bpf_map_update_elem(&result, &key, &val, BPF_ANY);
> +	return 0;

Will this not flake, like, maybe a lot? Mismatches are being reported
for every non-matched prefix. Meaning, other threads that are racing
alongside your system(3) invocations and going through
security_bprm_check() could very well reset your BPF_MAP_TYPE_ARRAY
element value back to -1 before your userspace code even has a chance
to assert it? Perhaps you can make this test a little more
deterministic by filtering by the expected PID?