Speakers
Description
Abstract
With klp-build now merged into mainline, establishing an automated test
suite is the logical next step. Historically, maintenance of
kpatch-build, a similar livepatching creation tool, has shown that the
object diff and correlation layer accounts for the vast majority of
regressions. Variations across compiler versions, optimization levels,
LTO modes, CFI, and architecture-specific handling in objtool's klp-diff
engine introduce a broad surface area where regressions can easily go
undetected.
The existing livepatch kselftests provide a proven model within the
subsystem. Developed alongside core livepatching functionality, they
have caught real bugs, e.g. covering shadow variables, callbacks, and state
transitions. All while remaining maintainable over time. klp-build
warrants a similar testing discipline, tailored to the toolchain layer.
We propose a two-tier testing strategy designed for both local developer
workflows and continuous integration:
Unit tests: Directly exercise objtool klp diff against minimal
.orig.o / .patched.o object pairs. Scripted assertions verify
symbol correlation, demangling, checksumming, special-section handling,
and relocations in seconds without requiring a full kernel build. To
adhere to kernel repository standards and avoid committing binary
artifacts, a CLI-driven runner regenerates test object pairs on demand
from module source and a kernel tree using the host/target toolchain.
Integration tests: Execute the complete klp-build pipeline against
dedicated in-tree test infrastructure (CONFIG_KLP_BUILD_TEST),
validating module post-linking and runtime livepatch loading on target
architectures.
Both tiers target a comprehensive architecture (x86_64, arm64,
LoongArch) and toolchain matrix (GCC, Clang, ThinLTO, CFI). Our goal is
to integrate these test suites into upstream CI infrastructure (e.g.,
CKI, KernelCI) to provide continuous regression testing across
configurations.
We invite discussion with the community on several key architectural and
integration questions:
Unit test granularity: Should tests target individual objtool
components (e.g., checksumming, correlation) independently, or is a
single objtool klp diff invocation per test case the appropriate
abstraction level?
In-tree vs. out-of-tree structure: Should integration tests reside
in-tree within kselftests while unit tests remain out-of-tree -- and
where should the test corpus generation tooling live?
Cross-version maintenance: How can in-tree integration test code be
structured to remain stable across kernel releases without incurring
unnecessary maintenance overhead?
CI pipeline integration: Should we integrate this this multi-arch,
multi-toolchain matrix into continuous integration platforms like CKI
and KernelCI?