tools/syz-verifier: cross-checking two kernels

[dvyukov]

Related to #200 gVisor is effectively another linux kernel implementation, so we could try to compare them side-by-side and maybe find some logical bugs. For starters we should just run corpus on linux once, capture results, run on gvisor, capture results and compare. This should give some idea about number of false positives.

[maramihali]

Edit to this issue:

syz-verifier aims to provide a utility for cross-checking any two kernels (with one important milestone being cross-checking gVisor against linux)

[maramihali]

Also, #2609 and #2649 and #2637

[dvyukov]

FTR here is an interesting example of a real regression: https://lwn.net/Articles/864947/ In short: edge-triggered epoll stopped unblocking threads if the buffer wasn't empty when a thread blocked.

[dvyukov]

FTR here is an announcement on regressions@ mailing list: https://lore.kernel.org/regressions/CACT4Y+byh0_z-+H3=-oojSLe+VesknKCXLPA5uVhue8zZaCb5A@mail.gmail.com/T/#m422d67aeed2f98f92b77b4fadcf779710ae33957

One idea proposed by Thorsten Leemhuis is that we can do something like git log --no-merges --oneline --grep "fix.*regression" fs/ | grep -v "performance regression" to get a list of past regressions to assess if syz-verifier is capable of finding them and make it find them.

[dvyukov]

Assorted improvement ideas:

1. syz-runner should create multiple parallel procs like syz-fuzzer does.
2. syz-runner should request new programs and return results in batches.
3. syz-runner should not create new ipc.Env for every program, and the syz-verifier -new-env flag should be removed. Instead syz-verifier should ask for new env only during reruns for higher fidelity.
4. syz-fuzzer should do host.Check/Setup like syz-fuzzer does.
5. syz-verifier should expose stats/logs in real-time via html interface (similar to syz-manager) for better introspection.