Message-ID: <513c854db04a727a20ad1fb01423497b3428eea6.camel@sipsolutions.net>
Date: Mon, 08 Sep 2025 15:11:08 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Ethan Graham <ethan.w.s.graham@...il.com>, ethangraham@...gle.com, 
	glider@...gle.com
Cc: andreyknvl@...il.com, brendan.higgins@...ux.dev, davidgow@...gle.com, 
	dvyukov@...gle.com, jannh@...gle.com, elver@...gle.com, rmoar@...gle.com, 
	shuah@...nel.org, tarasmadan@...gle.com, kasan-dev@...glegroups.com, 
	kunit-dev@...glegroups.com, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, 	dhowells@...hat.com, lukas@...ner.de,
 ignat@...udflare.com, 	herbert@...dor.apana.org.au, davem@...emloft.net,
 linux-crypto@...r.kernel.org
Subject: Re: [PATCH v2 RFC 0/7] KFuzzTest: a new kernel fuzzing framework

Hi Ethan,

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.

> This RFC continues to seek feedback on the overall design of KFuzzTest
> and the minor changes made in V2. We are particularly interested in
> comments on:
> - The ergonomics of the API for defining fuzz targets.
> - The overall workflow and usability for a developer adding and running
>   a new in-kernel fuzz target.
> - The high-level architecture.

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?

> 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. 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.)

I was just looking at what external state (such as the physical memory
mapped) UML has and that would need to be disentangled, and it's not
_that_ much if we can have specific configurations, and maybe mostly
shut down the userspace that's running inside UML (and/or have kunit
execute before init/pid 1 when builtin.)

Did you consider such a model at all, and have specific reasons for not
going in this direction, or simply didn't consider because you're coming
from the syzkaller side anyway?

johannes

Powered by blists - more mailing lists