Libguestfs - Oct 2022 - [libnbd PATCH] RFC: fuzzing: Break up handshake into more steps

On Fri, Oct 07, 2022 at 10:22:57AM +0100, Richard W.M. Jones
wrote:
> On Thu, Oct 06, 2022 at 04:34:52PM -0500, Eric Blake wrote:
> > Give the fuzzer a few more points to experiment with added branching
> > by explicitly using opt mode.
> > ---
> > 
> > I'm not quite sure whether the fuzzer is able to synthesize
specific
> > API calls from the client side; but if it can, letting the client
> > specifically enter the NEGOTIATING state may allow the fuzzer to spot
> > other nbd_opt_* API call chains that could provoke odd interactions,
> > which would be completely missed when sticking with the default of
> > skipping opt mode.
> 
> It's essentially looking for new paths through the code.  If the
> change allows new libnbd paths to be explored then it will be
> beneficial to fuzzing, if not then it'll make no difference.  I have
> no objection to trying the patch anyway, so ACK.
Ok, in as 8592caba

Thinking about ways to expose even more code-paths, I wonder if we
could tweak the client along the lines of:

if (rand () & 1)
  nbd_set_handshake_flags (nbd, rand ());
if (rand () & 1)
  nbd_set_strict_mode (nbd, rand ());

and so forth, to allow the fuzzer to explore different combinations of
settings.  Another idea might be:

static void do_opt_structured_reply (void)
{ /* call nbd_opt_structured_reply() */ }
static void do_opt_list_meta_context (void)
{ /* call nbd_opt_list_meta_context[_queries]() */ }
...
void (*opts[])(void) = {
  do_opt_structured_reply,
  do_opt_list_meta_context,
  ...
};

for (i = rand () % 20; i > 0; i--)
  opts[i % ARRAY_SIZE (opts)] ();

to play with different handshake sequences.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

On Fri, Oct 07, 2022 at 07:37:19AM -0500, Eric Blake
wrote:
> On Fri, Oct 07, 2022 at 10:22:57AM +0100, Richard W.M. Jones wrote:
> > On Thu, Oct 06, 2022 at 04:34:52PM -0500, Eric Blake wrote:
> > > Give the fuzzer a few more points to experiment with added
branching
> > > by explicitly using opt mode.
> > > ---
> > > 
> > > I'm not quite sure whether the fuzzer is able to synthesize
specific
> > > API calls from the client side; but if it can, letting the client
> > > specifically enter the NEGOTIATING state may allow the fuzzer to
spot
> > > other nbd_opt_* API call chains that could provoke odd
interactions,
> > > which would be completely missed when sticking with the default
of
> > > skipping opt mode.
> > 
> > It's essentially looking for new paths through the code.  If the
> > change allows new libnbd paths to be explored then it will be
> > beneficial to fuzzing, if not then it'll make no difference.  I
have
> > no objection to trying the patch anyway, so ACK.
> 
> Ok, in as 8592caba
> 
> Thinking about ways to expose even more code-paths, I wonder if we
> could tweak the client along the lines of:
> 
> if (rand () & 1)
>   nbd_set_handshake_flags (nbd, rand ());
> if (rand () & 1)
>   nbd_set_strict_mode (nbd, rand ());
Adding randomization to the fuzzer is a bad idea I'm afraid,
specifically called out in the docs:

https://aflplus.plus/docs/faq/ (search for "Stability")
> and so forth, to allow the fuzzer to explore different combinations of
> settings.
The fuzzer will explore different paths by presenting different
inputs.  In the case of libnbd, "input" means the network data that
normally libnbd would be reading from the NBD server.  As long as
variations in those replies (inputs) can cause libnbd to take
different paths then the fuzzer will eventually explore those paths.
> Another idea might be:
> 
> static void do_opt_structured_reply (void)
> { /* call nbd_opt_structured_reply() */ }
> static void do_opt_list_meta_context (void)
> { /* call nbd_opt_list_meta_context[_queries]() */ }
> ...
> void (*opts[])(void) = {
>   do_opt_structured_reply,
>   do_opt_list_meta_context,
>   ...
> };
> 
> for (i = rand () % 20; i > 0; i--)
>   opts[i % ARRAY_SIZE (opts)] ();
> 
> to play with different handshake sequences.
This won't work for the same reason.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v