On Mon, Sep 8, 2025 at 3:11 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > Hi Ethan, Hi Johannes, > Since I'm looking at some WiFi fuzzing just now ... > > > The primary motivation for KFuzzTest is to simplify the fuzzing of > > low-level, relatively stateless functions (e.g., data parsers, format > > converters) > > Could you clarify what you mean by "relatively" here? It seems to me > that if you let this fuzz say something like > cfg80211_inform_bss_frame_data(), which parses a frame and registers it > in the global scan list, you might quickly run into the 1000 limit of > the list, etc. since these functions are not stateless. OTOH, it's > obviously possible to just receive a lot of such frames over the air > even, or over simulated air like in syzbot today already. While it would be very useful to be able to test every single function in the kernel, there are limitations imposed by our approach. To work around these limitations, some code may need to be refactored for better testability, so that global state can be mocked out or easily reset between runs. I am not very familiar with the code in cfg80211_inform_bss_frame_data(), but I can imagine that the code doing the actual frame parsing could be untangled from the code that registers it in the global list. The upside of doing so would be the ability to test that parsing logic in modes that real-world syscall invocations may never exercise. > > As far as the architecture is concerned, I'm reading this is built > around syzkaller (like) architecture, in that the fuzzer lives in the > fuzzed kernel's userspace, right? > This is correct. > > We would like to thank David Gow for his detailed feedback regarding the > > potential integration with KUnit. The v1 discussion highlighted three > > potential paths: making KFuzzTests a special case of KUnit tests, sharing > > implementation details in a common library, or keeping the frameworks > > separate while ensuring API familiarity. > > > > Following a productive conversation with David, we are moving forward > > with the third option for now. While tighter integration is an > > attractive long-term goal, we believe the most practical first step is > > to establish KFuzzTest as a valuable, standalone framework. > > I have been wondering about this from another perspective - with kunit > often running in ARCH=um, and there the kernel being "just" a userspace > process, we should be able to do a "classic" afl-style fork approach to > fuzzing. This approach is quite popular among security researchers, but if I'm understanding correctly, we are yet to see continuous integration of UML-based fuzzers with the kernel development process. > That way, state doesn't really (have to) matter at all. This is > of course both an advantage (reproducing any issue found is just the > right test with a single input) and disadvantage (the fuzzer won't > modify state first and then find an issue on a later round.)
