Designing UAPI for Fuzz-ability
summary
Kernel fuzzing relies on concrete, machine-readable UAPI patterns: sisbot dashboard shows per-file coverage so you can see where fuzzers stall; subsystems that require real hardware go untested unless replaced by stubs or emulators; ideal stubs provide fresh transient instances (an ioctl that returns two file descriptors for device and control) so tests auto-cleanup. Avoid linked‑list collections, user‑space pointers-as-IDs, and convoluted cross-referenced blobs (netfilter example); try the k unit platform for platform emulation but it currently lacks widespread examples.
AI-written summary · about
chapters (8)
- 0:00Introduction to fuzzability
- 1:04Kernel fuzzing overview and coverage
- 3:12Hardware dependency challenges
- 7:51General kernel code recommendations
- 10:25Hardening kernel code for fuzzing
- 11:09API design for fuzzability
- 18:02Summary and best practices
- 19:57Q&A session
related talks
20mKFuzzTest: Targeted Fuzzing of Internal Kernel Functions
01h 15mMake your programs more reliable with Fuzzing
46mBypass Kernel Barriers: Fuzzing Linux Kernel in Userspace With LKL
31m“Fuzz or lose..."
32mFuzzing Zephyr Apps - Struggles of Dynamic Analysis on Embedded Applications
52mStructure aware fuzzing
21mFUZE: Towards Facilitating Exploit Generation for Kernel UAF Vulnerabilities
28mkAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels