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
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
