syz-execprog doesn't utilize info about fault injections from a prog log.
Since syz-execprog is used by the repro package to reproduce crashes,
crashes caused by fault injections might not reproduce.
If kernel or syzkaller binaries are rebuilt when manager uses them,
nothing good will happen. Manager can start mixing coverage from
old and new kernels, or crash on unknown syscalls.
Now each prog function accepts the desired target explicitly.
No global, implicit state involved.
This is much cleaner and allows cross-OS/arch testing, etc.
Repro can generate Sandbox="namespace"/UseTmpDir=false.
This combination is broken for two reasons:
- on second and subsequent executions of the program,
it fails to create syz-tmp dir
- with Procs>1, it fails right away, because all procs
try to create syz-tmp dir
Don't generate such combination.
We currently have 2 invalid options combinations:
- collide without threads
- procs>1 without repeat
They are invalid in the sense that result of csource.Write
is the same for them. Filter out these combinations.
This cuts csource testing time in half and reduces repro minimization time.
Sometimes C reproducers don't work after the generic prog options were
simplified. This change makes syzkaller to try extracting a C repro before
simplifying prog options and after each simplification step. This gives
us more chance to generate a C reproducer.
We can start reproducing one crash, but end up reproducing another.
Currently we still attribute the resulting repro to the original crash.
This is wrong.
Save the resulting desc/report for reproducers and use that in manager.
Currently we have unix permissions for new files/dirs
hardcoded throughout the code base. Some places use 0644,
some - 0640, some - 0600 and a variety of other constants.
Introduce osutil.MkdirAll/WriteFile that use the default
permissions and use them throughout the code base.
This makes permissions consistent and also allows to easily
change the permissions later if we change our minds.
Also merge pkg/fileutil into pkg/osutil as they become
dependent on each other. The line between them was poorly
defined anyway as both operate on files.
