Re: [PATCH v3 00/10] KFuzzTest: a new kernel fuzzing framework

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2025-12-17 at 11:19 +0100, Alexander Potapenko wrote:
> > > 
> > > As discussed at LPC, the tight tie between one single external user-space
> > > tool isn't something I am in favor of. The reason being, if the userspace
> > > app disappears all this kernel code stays with no way to trigger.
> > > 
> > > Ethan and I discussed at LPC and I asked Ethan to come up with a generic way
> > > to trigger the fuzz code that doesn't solely depend on a single users-space
> > > application.
> > > 
> > 
> > FWIW, the included kfuzztest-bridge utility works fine as a separate,
> > in-tree way of triggering the fuzz code. It's definitely not totally
> > standalone, but can be useful with some ad-hoc descriptions and piping
> > through /dev/urandom or similar. (Personally, I think it'd be a really
> > nice way of distributing reproducers.)
> > 
> > The only thing really missing would be having the kfuzztest-bridge
> > interface descriptions available (or, ideally, autogenerated somehow).
> > Maybe a simple wrapper to run it in a loop as a super-basic
> > (non-guided) fuzzer, if you wanted to be fancy.
> > 
> > -- David
> 
> An alternative Ethan and I discussed was implementing only
> FUZZ_TEST_SIMPLE for the initial commit.
> It wouldn't even need the bridge tool, because the inputs are
> unstructured, and triggering them would involve running `head -c N
> /dev/urandom > /sys/kernel/debug/kfuzztest/TEST_NAME/input_simple`
> This won't let us pass complex data structures from the userspace, but
> we can revisit that when there's an actual demand for it.

I feel like we had all this discussion before and I failed to be taken
seriously ;-)

For the record: I'm all for simplifying this. I had [1] looked into
integrating this framework with say afl++ or honggfuzz (the latter is
simpler due to the way coverage feedback is done) *inside* ARCH=um, but
this whole structured approach and lack of discoverability at runtime
(need to parse the debug data out of the kernel binary) basically throws
a wrench into it for (currently) nothing.

[1] other projects have taken precedence for now, unfortunately

And I do think it creates an effective dependency on syzkaller, running
via the bridge tool isn't something you can even do in such a context
since it's "userspace in the kernel" vs. "fuzzer integrated with the
(UML) kernel", you'd have to put the bridge tool into the kernel binary
somehow or so.

So to me, the bridge tool might be great for manual work (initial
development and reproducers) on a test, but I don't really see how it'd
be suitable for fuzzing runs. I expect it'd also be quite a speedbump,
and makes integrating coverage feedback harder too.

johannes