Extreme OS Kernel Testing
summary
A fuzz framework captures real kernel calls and filesystem objects from DTrace then randomizes them as a mad‑lib ordering; applied to FreeBSD it triggers a panic after eight hours with ~100 operations. A binary competition/champion reduction splits sets repeatedly to converge from 100 → 50 → 25 → 12 → 4 ops, cutting reproduction to ~30 seconds. The culprit sequence involves open/write/gcore/unlink with an open fd and zero link count; a C reproducer is produced and the bug is fixed and regressed.
AI-written summary · about
chapters (8)
- 0:00Start
- 0:08Lightning Talks
- 0:57Google File System
- 2:18Unix File Descriptor Model
- 4:07Non-Functional Testing
- 4:47Exploratory Testing
- 6:11Pesticide Paradox
- 12:14Sparse Files
related talks
20mKFuzzTest: Targeted Fuzzing of Internal Kernel Functions
24mA Case Study in Chaos Testing: Uncovering Kernel Scaling Issues
52mLinux Kernel Debugging: Going Beyond Printk Messages
50mWhat the Fuzz
46mBypass Kernel Barriers: Fuzzing Linux Kernel in Userspace With LKL
44mHands Off and Putting SLAB/SLUB Feng Shui in a Blackbox
39mFuzzing the Native NTFS Read-Write Driver (NTFS3) in the Linux Kernel
39mDay-to-day Testing of Linux 'Next' Kernel Branch - My Story