Hi, I would like to make a correction to my cover letter.
Note: v1 was sent as "RFC v2" due to my b4 misconfiguration. On 6/3/26 19:43, Yunseong Kim wrote: > Introduces a new KCOV exetened feature that captures function arguments and > return values at kernel function boundaries, enabling per-process visibility > into runtime dataflow. > > [snip...] kcov-dataflow are not in conflict with "KASAN_GENERIC + KCOV_DATAFLOW_INSTRUMENT_ALL" > Prerequisites / Toolchain > ========================= > > This kernel patch relies on a custom LLVM SanitizerCoverage pass that > emits __sanitizer_cov_trace_args() and __sanitizer_cov_trace_ret() > callbacks at function boundaries, extracting struct field layouts from > DWARF debug metadata at compile time. > > To build and test this patchset, compile the kernel using the modified > toolchain: > > 1. LLVM/Clang (adds -fsanitize-coverage=dataflow-args,dataflow-ret): > https://github.com/llvm/llvm-project/pull/201410 > > 2. Rust (rustc 1.98 built against the above LLVM 23, for Rust module support): > https://github.com/yskzalloc/rust > > Build instructions: > > # Build the modified clang > cd llvm-project && cmake -G Ninja -S llvm -B build \ > -DLLVM_ENABLE_PROJECTS="clang;lld" -DCMAKE_BUILD_TYPE=Release > ninja -C build clang > > # Build the kernel with dataflow support > export PATH=$HOME/llvm-project/build/bin:$PATH > export RUSTC=$HOME/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc > export RUST_LIB_SRC=$HOME/rust/library > > make LLVM=1 defconfig > scripts/config --enable KCOV \ > --enable KCOV_DATAFLOW_ARGS \ > --enable KCOV_DATAFLOW_RET > make LLVM=1 olddefconfig > make LLVM=1 -j$(nproc) > > Note: CONFIG_KCOV_DATAFLOW_ARGS and CONFIG_KCOV_DATAFLOW_RET depend on > CONFIG_KCOV and use $(cc-option) to verify the compiler supports the > new flags. With standard (unpatched) clang, these options will not > appear in menuconfig and silently remain disabled. > > Optional configs: > --enable KCOV_DATAFLOW_INSTRUMENT_ALL (instrument entire kernel) > --enable KCOV_DATAFLOW_NO_INLINE (enabled by default) I checked, and it’s better to use CONFIG_FRAME_WARN=0 when using KASAN together regarding flood of -Wframe-larger-than warnings. > --set-val FRAME_WARN 4096 (needed for INSTRUMENT_ALL) > --disable KASAN (conflicts with INSTRUMENT_ALL) > --enable KASAN (no conflicts; works well, but slower, a lot of dataflow) What I meant by that conflicts is that I was using it for kernel-space behavior only for the "offensive kernel vulnerability auditing", and in that case, sometime it’s better to disable KASAN. Tested CONFIG_KASAN=y + CONFIG_KCOV_DATAFLOW_INSTRUMENT_ALL=y together (FRAME_WARN=4096, virtme-ng 1 vCPU 1GB on my Intel CPU Dell Pro 14 Premium PA14250): - Builds clean, no frame size warnings - Boots and runs without KASAN errors - kcov-dataflow captures correctly under KASAN: getpid(): 6,682 records open+close: 16,382 records (filled 64K buffer) Time to "Freeing unused kernel image (initmem)": KCOV_DATAFLOW_INSTRUMENT_ALL only: ~0.95s (+40%) KASAN + KCOV_DATAFLOW_INSTRUMENT_ALL: ~2.02s (+197%) Sorry for any confusion the earlier wording may have caused. Thank you! Kind regards, Yunseong
