Re: [PATCH bpf-next 3/4] libbpf: Detect BPF_TRACE_UPROBE support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] libbpf: broken BPF_TRACE_UPROBE detection in probe_kern_uprobe_attach_type()
--

commit daaaf792d9bbc9ce6b848daf8f14739d2eddbab7
Author: Jiri Olsa <jolsa@kernel.org>

libbpf: Detect BPF_TRACE_UPROBE support

This commit probes whether the kernel supports BPF_TRACE_UPROBE as the
expected attach type for BPF_PROG_TYPE_KPROBE programs and sets it for
uprobe, uretprobe, and usdt sections when supported.

> diff --git a/tools/lib/bpf/features.c b/tools/lib/bpf/features.c
> index adb5d2e7fdfa2..175d96c0a5012 100644
> --- a/tools/lib/bpf/features.c
> +++ b/tools/lib/bpf/features.c
> @@ -318,6 +318,24 @@ static int probe_kern_exp_attach_type(int token_fd)
>  	return probe_fd(fd);
>  }
>  
> +static int probe_kern_uprobe_attach_type(int token_fd)
> +{
> +	LIBBPF_OPTS(bpf_prog_load_opts, opts,
> +		.expected_attach_type = BPF_TRACE_UPROBE,
> +		.token_fd = token_fd,
> +		.prog_flags = token_fd ? BPF_F_TOKEN_FD : 0,
> +	);
> +	struct bpf_insn insns[] = {
> +		BPF_MOV64_IMM(BPF_REG_0, 0),
> +		BPF_EXIT_INSN(),
> +	};
> +	int fd;
> +
> +	fd = bpf_prog_load(BPF_PROG_TYPE_KPROBE, NULL, "GPL", insns,
> +			   ARRAY_SIZE(insns), &opts);
> +	return probe_fd(fd);
> +}

[Severity: Medium]
Does probe_kern_uprobe_attach_type() actually detect whether the running
kernel supports BPF_TRACE_UPROBE?

In kernel/bpf/syscall.c, bpf_prog_load() does not reject
attr->expected_attach_type >= __MAX_BPF_ATTACH_TYPE, and
bpf_prog_load_check_attach() has no case for BPF_PROG_TYPE_KPROBE, so it
falls through to the default branch and returns 0:

kernel/bpf/syscall.c:bpf_prog_load_check_attach() {
    ...
	case BPF_PROG_TYPE_SYSCALL:
	case BPF_PROG_TYPE_EXT:
		if (expected_attach_type)
			return -EINVAL;
		fallthrough;
	default:
		return 0;
	}
}

Because BPF_PROG_LOAD has accepted any expected_attach_type value for
BPF_PROG_TYPE_KPROBE since Linux 4.17 (when token_fd is 0),
probe_kern_uprobe_attach_type() will return 1 even on older kernels that do
not know about BPF_TRACE_UPROBE.

When bpf_object__load() -> bpf_object_load_prog() ->
libbpf_prepare_prog_load() then sets prog->expected_attach_type and
opts->expected_attach_type to BPF_TRACE_UPROBE on those older kernels:

tools/lib/bpf/libbpf.c:libbpf_prepare_prog_load() {
    ...
	if ((def & SEC_UPROBE) && kernel_supports(prog->obj, FEAT_UPROBE_ATTACH_TYPE)) {
		prog->expected_attach_type = BPF_TRACE_UPROBE;
		opts->expected_attach_type = BPF_TRACE_UPROBE;
	}
    ...
}

can this cause regressions for existing programs? For example:

1. In kernel/bpf/core.c, bpf_prog_map_compatible() requires matching
expected_attach_type values for BPF_MAP_TYPE_PROG_ARRAY:

kernel/bpf/core.c:bpf_prog_map_compatible() {
    ...
		if (ret &&
		    map->map_type == BPF_MAP_TYPE_PROG_ARRAY &&
		    map->owner->expected_attach_type != fp->expected_attach_type)
			ret = false;
    ...
}

Sharing a tail-call map between a SEC("uprobe") program (loaded with
expected_attach_type == BPF_TRACE_UPROBE) and a SEC("kprobe") program
(loaded with expected_attach_type == 0) will now fail.

2. Callers checking bpf_program__expected_attach_type() will observe
BPF_TRACE_UPROBE on kernels that neither enforce uprobe-only attach nor
disable the private stack for BPF_TRACE_UPROBE.

3. If FEAT_UPROBE_ATTACH_TYPE is cached without a token and later used when
loading a program with a BPF token on kernels 6.9+ prior to
BPF_TRACE_UPROBE, bpf_token_allow_prog_type() in kernel/bpf/token.c will
reject the load because attach_type >= __MAX_BPF_ATTACH_TYPE.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103093400.112178-1-jolsa@kernel.org?part=3