[PATCH passt v2 0/7] Add fuzzing

["Richard W.M. Jones" <rjones@redhat.com>]

With this series, fuzzing actually works, albeit slowly.  More on that
below.

Patches 1 & 2 are the same as before.

Patch 3 is Stefano Brivio's modified patch (with some changes that we
discussed together on IRC but otherwise unchanged).

Patch 4 is new, but discussed already upstream: It changes the order
in which EPOLLIN and EPOLLRDHUP events are processed, so that we don't
drop packets when the socket is closed.

Patches 5 & 6 are the hacks that were needed to get fuzzing to work.
Patch 6 removes all seccomp and other isolation stuff because for
unclear reasons that breaks AFL instrumentation.  AFL appears to fork
off a second process, and somehow strace cannot follow that process,
but the second process fails, and that breaks AFL completely.  Without
strace data it's rather hard to see what's going on so I didn't
investigate this further.

Patch 7 adds the fuzzing wrapper and is not greatly changed from
before.  However I did have to disable the AFL "fork server"
optimization which somehow doesn't work with passt (it does work fine
with libnbd & nbdkit).

Speed is not great.  I'm getting ~ 75-80 execs/second.  Really we want
this to be much higher, since that ultimately governs how fast we can
explore new code paths and find bugs.  Ideally well over 1000 execs/s
(per fuzzing process) would be a good target to aim for.  (Of course
this depends on the hardware as well.)

We could try to find out why the fork server is not compatible with
passt, but I don't think we'd gain very much performance there.  To
explore this I ran a dummy fuzzed process from the same wrapper, and
it was hardly any faster.

I think the real gains are going to come from reducing the overhead of
starting passt.  There seem to be some netlink messages sent during
start up and maybe if those could be reduced or eliminated we might
see better performance.

The other factor is fuzzing stability, which hovers around 87-90%.
While this isn't necessarily bad, I wonder where the non-determinism
is coming from [ideal figures would be 95-100%].  Passt doesn't appear
to use threads.  It does call getrandom (for TCP sequence numbers) so
it'd be good to have a way to bypass that.  However I don't fully
understand what's going on here.

Rich.