No, it does not work:
Error 400: Invalid value for field 'resource.scheduling.preemptible': 'true'. Scheduling must have preemptible be false when OnHostMaintenance isn't TERMINATE
Currently syzkaller uses per-call basic block (BB) coverage.
This change implements edge (not-per-call) coverage.
Edge coverage is more detailed than BB coverage as it captures
not-taken branches, looping, etc. So it provides better feedback signal.
This coverage is now called "signal" throughout the code.
BB code coverage is also collected as it is required for visualisation.
Not doing per-call coverage reduces corpus ~6-7x (from ~35K to ~5K),
this has profound effect on fuzzing efficiency.
Using `adb shell syz-executor reboot` to reboot devices has stopped
working with the recent Android update, probably due to the intro
of seccomp. I have reverted the device reboot logic to use `adb
shell reboot` although it can be flaky at times so that we can
continue to fuzz on devices, until a more reliable solution can be
sought out.
This change adds a `csum[kind, type]` type.
The only available kind right now is `ipv4`.
Using `csum[ipv4, int16be]` in `ipv4_header` makes syzkaller calculate
and embed correct checksums into ipv4 packets.
Fuzzer has figured out how to corrupt input/output shmem regions
abusing the text memcpy in syz_kvm_setup_cpu. It guessed a negative
text_size value that causes the memcpy to overwrite shmem regions.
Protect better against such cases:
1. Make text_size unsigned (there is already a check that it is less than 1000).
2. Map input region as readable only, we don't write to it.
3. Add address sanity check to segv_handler, if we see that we are writing
into executable data, it's better to crash instantly.
The optimization change removed validation too aggressively.
We do need program validation during deserialization,
because we can get bad programs from corpus or hub.
Restore program validation after deserialization.
A bunch of spot optmizations after cpu/memory profiling:
1. Optimize hot-path coverage comparison in fuzzer.
2. Don't allocate and copy serialized program, serialize directly into shmem.
3. Reduce allocations during parsing of output shmem (encoding/binary sucks).
4. Don't allocate and copy coverage arrays, refer directly to the shmem region
(we are not going to mutate them).
5. Don't validate programs outside of tests, validation allocates tons of memory.
6. Replace the choose primitive with simpler switches.
Choose allocates fullload of memory (for int, func, and everything the func refers).
7. Other minor optimizations.
Currently we generate arrays of size [0,5] with equal probability.
Generate [0,10] with bias towards smaller arrays. But 0 has the lowest probability.
I've benchmark a slightly different change with max array size of 20,
results are somewhat inconclusive: it was better than baseline almost all way,
but baseline suddenly caught up at the end. It also considerably reduced
executions per second (by ~20%). So increasing array size to 10 should be a win...
Currently we generate 1 program per 9 mutations.
Do it per 99 mutations.
Benchmark shows both coverage increase and corpus reduction:
baseline generate100 diff
coverage 65467 65569 102
corpus 35423 35363 -60
exec total 5474879 5030990 -443889
Currently we stop mutating with 50% probability.
Stop mutating with 33% probability instead.
Benchmark shows both coverage increase and corpus reduction:
baseline oneof3 diff
coverage 65467 65604 137
corpus 35423 35354 -69
exec total 5474879 5023268 -451611
kcovtrace is like strace but show kernel coverage collected with KCOV.
It is very simplistic at this point and does not support multithreaded processes, etc.
It can be used to understand, for example, exact location where kernel bails out
with an error for a particular syscall.
In benchmarking mode (if the new -bench flag is specified)
syz-manager writes execution statistics into the specified file.
This allows later comparison of different runs (baseline vs some experiment).
For example, verify that some fuzzing modification indeed leads to larger coverage.