Re: [RFC PATCH v2 0/6] kcov: per-task dataflow extraction at kernel function boundaries

[Yunseong Kim <yunseong.kim@est.tech>]

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