Re: [RFC PATCH v2 3/3] bpftool: Prefer zlib-rs over zlib when available

[Quentin Monnet <qmo@kernel.org>]

Hi Ian, thanks for the v2,


2026-10-30 13:27 UTC-0700 ~ Ian Rogers <irogers@google.com>
> Add zlib-rs and zlib to FEATURE_TESTS and FEATURE_DISPLAY in
> tools/bpf/bpftool/Makefile and use feature_rust_lib to configure
> ZLIB_CFLAGS and ZLIB_LIBS when zlib-rs is detected (unless disabled with
> NO_ZLIB_RS=1), falling back to -lz.
> 
> Decompression of kernel configuration (/proc/config.gz) and compressed
> ELF/BTF sections (via libbpf, libelf, and libbfd) processes data that


Is there any mechanism in place that prevents libbpf, libelf, and libbfd
to link to different versions of zlib (zlib vs zlib-rs, I mean)? I
imagine you could have bpftool linking against zlib-rs, but the libs
installed on the system linking against zlib? Also I think the static
build with the LLVM disassembler [0] passes -lz -lzstd in LIBS and I'm
not sure how it would combine with the change, I need to take a closer look.


> benefits from a memory-safe implementation. Preferring zlib-rs over C
> zlib provides memory safety and improved decompression performance while
> keeping bpftool aligned with tools/perf (including sharing libz_rs.a
> when building bootstrap bpftool for perf BPF skeletons).
> 
> Signed-off-by: Ian Rogers <irogers@google.com>

Recalling our discussion from v1:

>> Hi Ian, bpftool doesn't make an intensive use of zlib (mostly, it's a
>> requirement from other dependencies; we may also use it to unzip the
>> kernel config on the host if necessary for probing BPF features on the
>> system, but only on some distributions). So I'm struggling to understand
>> the motivation for your proposal, what do we gain by switching to
>> zlib-rs when available? I understand this implementation is in Rust, but
>> I'm not sure the added complexity and feature probing in the build
>> system is worth it.
> 
> Hi Quentin,
> 
> At my workplace, we are transitioning from zlib to zlib-rs for both
> security and performance reasons. I'd like to keep upstream tools
> aligned but they don't have to be, it just seems nice. I agree zlib is
> of a lower priority to users than, say, zstd. For attackers, like with
> brotli, it is probably an area of interest. Knowing the implementation
> is memory safe is at least something in favor of zlib-rs. I sent this
> series out as an RFC because I obviously have no way to mandate what
> upstream should or shouldn't be doing. There are things that can make
> life a little nicer and easier, and this patch series, for me, is one
> of them.
I understand you're transitioning to zlib-rs, but the current patch is
not a full transition, in the sense that it doesn't replace zlib with
zlib-rs but allows any of the two options; and I don't see support for
the standard zlib being removed from bpftool anytime soon, which means
that in practice, we've got to maintain compatibility with the two
versions going forward. Others may want to chime in, but I'm still not
convinced this is worth the burden.

You also mention zstd, do you plan to add support for a zstd alternative
as well in perf and bpftool in the future?

(By the way, if you allow me a short digression, you had a patch related
to the zstd probing for perf and bpftool [0] and I don't see in the
tree, do you know if it was ever merged?)

Best regards,
Quentin


[0]
https://github.com/libbpf/bpftool/blob/main/.github/workflows/static-build.yaml
[1] https://lore.kernel.org/all/20260909204122.1993010-4-irogers@google.com/