Severe compatibility fragility across modern kernels, BTF layouts, and LLVM toolchains

[MisterHk]

Hello,

After spending many hours debugging and manually troubleshooting GhostScan on a modern Kali Linux rolling environment, I believe the project currently has a much deeper compatibility problem than the documentation suggests.

This is not simply a missing dependency issue or a minor compiler warning.

The root problem appears to be architectural sensitivity to:

• rapid kernel evolution
• BTF layout changes
• LLVM/clang diagnostic behavior
• eBPF ecosystem instability across rolling distributions

Environment tested:

• Kali Linux Rolling

• Kernel: 6.19.14+kali-amd64

• clang tested:

  • 21.1.8
  • 19.1.7

• current Rust/Cargo toolchain

• bpftool installed

• libbpf-dev installed

• autotools/build dependencies installed

During troubleshooting I had to manually resolve:

• autoreconf requirements
• autopoint requirements
• bison requirements
• bpftool requirements
• libbpf headers
• clang compatibility issues
• cargo build environment issues

After resolving all missing dependencies, the build still fails during BPF compilation because the generated vmlinux.h from modern kernels introduces declarations that clang now treats differently.

The current build system uses:
.args(["-target", "bpf", "-O2", "-g", "-Wall", "-Werror"])

This immediately turns modern kernel/BTF compatibility warnings into fatal build failures.

Examples from generated vmlinux.h:

• struct ns_tree;
• struct freelist_tid;
• union pipe_index;
• struct freelist_counters;

clang reports:
"declaration does not declare anything [-Wmissing-declarations]"

Removing -Werror manually allows the build to proceed further, which strongly suggests the project is currently too fragile against newer kernel and LLVM environments.

The larger concern is this:

GhostScan deeply depends on generated kernel structures, BTF output, eBPF helpers, and low-level kernel internals.

That means every major kernel update, LLVM update, or BTF layout change can potentially break the project.

At the moment there seems to be:

• no documented compatibility matrix
• no tested kernel matrix
• no documented LLVM/clang requirements
• no containerized reproducible environment
• no troubleshooting documentation
• no guidance for rolling distributions

The current “Quick Start” instructions dramatically underestimate the real complexity involved in compiling and running the project on modern systems.

For a tool operating at this level of kernel/eBPF depth, reproducibility and compatibility management are essential.

Without stronger compatibility controls, the project risks becoming extremely difficult to build outside the original developer environment.

Suggestions:

1. Remove -Werror from BPF compilation
2. Add selective warning suppression for known kernel/BTF declaration patterns
3. Publish supported kernel versions
4. Publish supported clang/LLVM versions
5. Add CI testing against multiple kernels
6. Provide Docker/containerized builds
7. Add troubleshooting documentation for rolling distributions
8. Consider shipping prebuilt binaries for known-good environments

Despite the difficulties, the project itself is technically impressive and clearly ambitious.

The scanner design and DFIR coverage are excellent.

However, the current installation and compatibility experience is significantly more fragile than the documentation implies.

I hope this report helps improve portability, maintainability, and adoption across modern Linux environments.