Re: [PATCH bpf-next v4 2/2] bpftool: Make the LLVM disassembler an optional runtime dependency

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpftool: resolving LIBLLVM_SO with realpath breaks dlopen() in disasm_init()
--

commit 97021edb72f7e0a08dad16e3c0be0bb0e347592d
Author: Mark Korenberg <socketpair@gmail.com>

bpftool: Make the LLVM disassembler an optional runtime dependency

This commit avoids linking bpftool directly against shared libLLVM.so at
build time and instead loads it dynamically with dlopen() and dlsym() in
disasm_init() when running "bpftool prog dump jited".

Link: https://github.com/libbpf/bpftool/issues/262

> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> index b0f7168e79432..876bf3cf93e3b 100644
> --- a/tools/bpf/bpftool/Makefile
> +++ b/tools/bpf/bpftool/Makefile
> @@ -186,10 +186,18 @@ ifeq ($(HAS_LLVM),1)
>    # Makefile includes lib.mk which sets -D_GNU_SOURCE) which would cause
>    # compilation error due to redefinition. Let's filter it out here.
>    CFLAGS  += $(filter-out -D_GNU_SOURCE,$(shell $(LLVM_CONFIG) --cflags))
> -  LIBS    += $(shell $(LLVM_CONFIG) --libs $(LLVM_CONFIG_LIB_COMPONENTS))
> +  LIBLLVM_SO := $(shell $(LLVM_CONFIG) --libfiles $(LLVM_CONFIG_LIB_COMPONENTS))
>    ifeq ($(shell $(LLVM_CONFIG) --shared-mode),static)
> +    LIBS += $(shell $(LLVM_CONFIG) --libs $(LLVM_CONFIG_LIB_COMPONENTS))
>      LIBS += $(shell $(LLVM_CONFIG) --system-libs $(LLVM_CONFIG_LIB_COMPONENTS))
>      LIBS += -lstdc++
> +  else ifeq ($(words $(LIBLLVM_SO)),1)
> +    # Don't link with libLLVM.so. "prog dump jited" loads it with dlopen().
> +    CFLAGS += -DLIBLLVM_SO='"$(notdir $(realpath $(LIBLLVM_SO)))"'

[Severity: Medium]
Will resolving LIBLLVM_SO with $(notdir $(realpath $(LIBLLVM_SO))) cause
dlopen(LIBLLVM_SO, RTLD_NOW) in disasm_init() to fail on distributions such
as Debian and Ubuntu, or across point-release upgrades?

Because $(notdir ...) strips the directory path and LDFLAGS only receives
llvm-config --ldflags without an rpath, dlopen() in
do_dump()->disasm_init() searches only the default runtime dynamic loader
paths:

tools/bpf/bpftool/jit_disasm.c:disasm_init() {
	...
	lib = dlopen(LIBLLVM_SO, RTLD_NOW);
	if (!lib) {
		p_err("failed to load %s: %s", LIBLLVM_SO,
		      dlerror() ?: "unknown error");
		return -1;
	}
	...
}

On Debian and Ubuntu, the runtime package installs the actual shared object
at /usr/lib/llvm-X/lib/libLLVM.so.1 (a private directory not in the default
ld.so search path) and exposes it in /usr/lib/<multiarch>/ only through
symlinks named after the ELF soname (such as libLLVM.so.19.1 or
libLLVM-19.so.1). Applying realpath resolves the symlink back to
/usr/lib/llvm-X/lib/libLLVM.so.1, and notdir turns that into "libLLVM.so.1",
which does not exist in /usr/lib/<multiarch>/.

Similarly, on builds where libLLVM.so is a symlink chain through the soname
(for example libLLVM.so.20.1) to a full point-release filename (for example
libLLVM.so.20.1.8), realpath bypasses the soname symlink and embeds the
exact point-release filename, which breaks dlopen() after a point-release
update of the runtime package.

Would it be better to extract the ELF soname from $(LIBLLVM_SO) (for example
with readelf or objdump) instead of using realpath?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-bpftool-plugin-v4-0-5a853e973db9@gmail.com?part=2