Re: [PATCH bpf-next] libbpf: Resolve typeless ksyms in the kernel

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] libbpf: weak LTO ksyms fail to resolve and silently default to zero
- [Medium] libbpf: fast path bypasses ksym ambiguity check
--

commit fc5b255aa262ee9f680fe13bd2bcb9fc56ff8a8d
Author: Samuel Wu <wusamuel@google.com>

libbpf: Resolve typeless ksyms in the kernel

This commit optimizes the resolution of typeless kernel symbols by using a
BPF_PROG_TYPE_SYSCALL program to call bpf_kallsyms_lookup_name() in the
kernel. This reduces load time significantly by avoiding a linear scan of
/proc/kallsyms in the fast path, while falling back to the legacy parser
if the kernel resolution fails.

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -9590,6 +9590,58 @@ static int bpf_object__read_kallsyms_file(struct bpf_object *obj)
[ ... ]
> +static int bpf_object__resolve_ksyms_in_kernel(struct bpf_object *obj)
> +{
[ ... ]
> +	for (i = 0; i < obj->nr_extern; i++) {
> +		ext = &obj->externs[i];
> +		if (ext->type != EXT_KSYM || ext->ksym.type_id)
> +			continue;
> +		if (snprintf(ctx.name, sizeof(ctx.name), "%s", ext->name) >= sizeof(ctx.name)) {
> +			err = -ENAMETOOLONG;
> +			break;
> +		}
> +		err = bpf_prog_test_run_opts(prog_fd, &topts) ?: (int)topts.retval;

[Severity: Medium]
Does this fast path bypass the ambiguity checks normally enforced by the legacy
kallsyms parser?

In the legacy parser, kallsyms_cb() enforces a strict ambiguity check and
returns -EINVAL if a symbol name maps to multiple addresses. However,
bpf_kallsyms_lookup_name() simply returns the first matched address.

If the fast path succeeds, ambiguous symbols might be silently accepted. If the
fast path fails for any reason (such as older kernels without support, or an
unrelated missing strong symbol triggering a fallback), it drops into the legacy
parser which then unpredictably rejects those same ambiguous symbols. Could this
lead to non-deterministic behavior depending on which path is taken?

> +		if (err == -ENOENT && ext->is_weak) {
> +			err = 0;
> +			continue;
> +		}

[Severity: Medium]
When bpf_kallsyms_lookup_name() fails to find a weak LTO symbol (like those
ending in .llvm.<hash>) because it expects an exact string match, this block
clears the -ENOENT error and continues. 

Because the error is cleared to 0, bpf_object__resolve_ksyms_in_kernel() will
ultimately return success for this missing symbol.

Will this cause the caller to unintentionally skip the necessary fallback logic?

In bpf_object__resolve_externs(), the fallback to
bpf_object__read_kallsyms_file() is only triggered if
bpf_object__resolve_ksyms_in_kernel() returns a non-zero error. By clearing
the error here, the /proc/kallsyms fallback is bypassed, meaning weak LTO
symbols that are actually present in the kernel might silently default to zero
instead of resolving properly.

> +		if (err)
> +			break;
> +		ext->is_set = true;
> +		ext->ksym.addr = ctx.addr;
> +		pr_debug("extern (ksym) '%s': resolved in kernel to 0x%llx\n",
> +			 ext->name, ext->ksym.addr);
> +	}
> +	close(prog_fd);
> +	return err;
> +}
[ ... ]
> @@ -9863,7 +9915,12 @@ static int bpf_object__resolve_externs(struct bpf_object *obj,
[ ... ]
>  	if (need_kallsyms) {
> -		err = bpf_object__read_kallsyms_file(obj);
> +		err = bpf_object__resolve_ksyms_in_kernel(obj);
> +		if (err) {
> +			pr_debug("failed to resolve ksyms in kernel: %s, falling back to /proc/kallsyms\n",
> +				 errstr(err));
> +			err = bpf_object__read_kallsyms_file(obj);
> +		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009130708.1370675-1-wusamuel@google.com?part=1