Libguestfs - Sep 2023 - [libnbd PATCH v2 2/6] fuzzing: Disable client-side strictness checks

When fuzzing, it is more desirable to always provoke the server into
sending a response, rather than sometimes accidentally skipping a wire
call because a client-side strictness test failed.

[Our fuzzer could probably be made even more powerful by changing the
fuzzer input file to be a series of records, where each record is the
API to call and then the server's response; right now, the sequence of
APIs called is hard-coded, which is not as powerful at testing
potential cross-command coupling. But that's a project for another
day.]

Signed-off-by: Eric Blake <eblake at redhat.com>
Reviewed-by: Richard W.M. Jones <rjones at redhat.com>
Reviewed-by: Laszlo Ersek <lersek at redhat.com>
---
 fuzzing/libnbd-fuzz-wrapper.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fuzzing/libnbd-fuzz-wrapper.c b/fuzzing/libnbd-fuzz-wrapper.c
index cbd55380..fcd1d04c 100644
--- a/fuzzing/libnbd-fuzz-wrapper.c
+++ b/fuzzing/libnbd-fuzz-wrapper.c
@@ -193,8 +193,11 @@ client (int sock)
   }

   /* Note we ignore errors in these calls because we are only
-   * interested in whether the process crashes.
+   * interested in whether the process crashes.  Likewise, we don't
+   * want to accidentally avoid sending traffic to the server merely
+   * because client side strictness sees a problem.
    */
+  nbd_set_strict_mode (nbd, 0);

   /* Enable a metadata context, for block status below. */
   nbd_add_meta_context (nbd, LIBNBD_CONTEXT_BASE_ALLOCATION);
-- 
2.41.0

On Thu, Sep 21, 2023 at 03:58:01PM -0500, Eric Blake
wrote:
> When fuzzing, it is more desirable to always provoke the server into
> sending a response, rather than sometimes accidentally skipping a wire
> call because a client-side strictness test failed.
> 
> [Our fuzzer could probably be made even more powerful by changing the
> fuzzer input file to be a series of records, where each record is the
> API to call and then the server's response; right now, the sequence of
> APIs called is hard-coded, which is not as powerful at testing
> potential cross-command coupling. But that's a project for another
> day.]
Intrigued by how this would work exactly.  The current file is just a
stream of bytes from the "server" (the output from libnbd is
discarded).  Would the input file be of the form:

  ( [ request + args ] [ stream of bytes from server ] )*

where [ request + args ] would be a simple serialized representation
of a synchronous nbd_* API call?  I think that would work ...

Rich.
> Signed-off-by: Eric Blake <eblake at redhat.com>
> Reviewed-by: Richard W.M. Jones <rjones at redhat.com>
> Reviewed-by: Laszlo Ersek <lersek at redhat.com>
> ---
>  fuzzing/libnbd-fuzz-wrapper.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/fuzzing/libnbd-fuzz-wrapper.c b/fuzzing/libnbd-fuzz-wrapper.c
> index cbd55380..fcd1d04c 100644
> --- a/fuzzing/libnbd-fuzz-wrapper.c
> +++ b/fuzzing/libnbd-fuzz-wrapper.c
> @@ -193,8 +193,11 @@ client (int sock)
>    }
> 
>    /* Note we ignore errors in these calls because we are only
> -   * interested in whether the process crashes.
> +   * interested in whether the process crashes.  Likewise, we don't
> +   * want to accidentally avoid sending traffic to the server merely
> +   * because client side strictness sees a problem.
>     */
> +  nbd_set_strict_mode (nbd, 0);
> 
>    /* Enable a metadata context, for block status below. */
>    nbd_add_meta_context (nbd, LIBNBD_CONTEXT_BASE_ALLOCATION);
> -- 
> 2.41.0
-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top