Conveners
Kernel Testing & Dependability MC
- Sasha Levin
- Shuah Khan (The Linux Foundation)
- Guillaume Tucker
- Arisu Tachibana
Description
The Kernel Testing & Dependability Micro-Conference (a.k.a. Testing MC) focuses on advancing the current state of testing of the Linux Kernel and its related infrastructure.
Building upon the momentum from previous years, the Testing MC's main purpose is to promote collaboration between all communities and individuals involved with kernel testing and dependability. We aim to create connections between folks working on related projects in the wider ecosystem and foster their development. This should serve applications and products that require predictability and trust in the kernel.
We ask that all discussions focus on some identified issues, aiming at finding potential solutions or alternatives to resolving them. The Testing MC is open to all topics related to testing on Linux, not necessarily in the kernel space.
In particular, here are some popular topics from past editions:
- KernelCI: Maestro, kci-dev, kci-deploy, kci-gitlab, new dashboard, KCIDB
- Improve sanitizers: KFENCE, KCSAN, KASAN, UBSAN
- Using Clang for better testing coverage: Now that the kernel fully supports building with Clang, how can all that work be leveraged into using Clang's features?
- Consolidating toolchains: reference collection for increased reproducibility and quality control.
- How to spread KUnit throughout the kernel?
- Building and testing in-kernel Rust code.
- Identify missing features that will provide assurance in safety critical systems.
- Which test coverage infrastructures are most effective to provide evidence for kernel quality assurance? How should it be measured?
- Explore ways to improve testing framework and tests in the kernel with a specific goal to increase traceability and code coverage.
- Regression Testing for safety: Prioritize configurations and tests critical and important for quality and dependability.
- Transitioning to test-driven kernel release cycles for mainline and stable: How to start relying on passing tests before releasing a new tag?
- Explore how do SBOMs figure into dependability?
- kernel benchmarking and kernel performance evaluation
Things accomplished from last year:
- progress on Rust testing
- kci-dev is currently used in production for interacting with KernelCI results
- Follow up discussions on kselftest mailing list about "Adding benchmarks results support to KTAP/kselftest"
- Proposal of kci-gitlab sent to kselftest mailing list
Today the kernel's UAPIs are tested through userspace testcases using the kselftests framework, which provides a uniform build system and output formatting infrastructure. However it does currently not provide an out-of-the-box solution to run the tests against the current in-development kernel tree.
I am proposing a framework which allows to build the test applications as part of the...
The kernel testing ecosystem is roughly split into kernelspace tests, commonly implemented using the KUnit framework, and an assortment of userspace tests, the most representative of which are kselftests.
Both types have different goals and are used differently: while KUnit tests are meant to be run in a known scenario on a freshly booted kernel, with little or no interactions and no...
Fuzzing the Linux kernel with coverage-guided tools like syzkaller has proven to be an extremely effective method for finding kernel bugs. However, complex subsystems like KVM present unique and significant challenges that standard syscall fuzzing cannot easily address. Fuzzing KVM effectively requires managing complex state across both the host and the guest, and necessitates the coordinated...
The [kdevops][1] project automates complex Linux kernel development subsystem testing. Around Q3 we started evaluating advances in generative AI. The experimentation on kdevops shows project significantly enhances the speed and accuracy of generative AI for extending its features and adding new workflows. This capability was a core design principle. While generative [AI may not yet be optimal...