Add bisect.py script

[hogander-unikie]

Add new script bisect.py to run syz-bisect to given reproducer c source files.

This patch depend on syzkaller pull request. https://github.com/google/syzkaller/pull/1700

[dvyukov]

I think we should improve syz-bisect interface instead. I don't see this providing significant additional value on top of just converting the way things are passed in to syz-bisect. And at the same time it too over-specified for your particular case and does not allow to specify lots of important things (repro.opts, VM type, procs, that http port may be busy, etc). I don't mind if we change syz-bisect -crash flag to a set of separate flags like this script accepts. The way -crash works was just handy for my early experiments. The manager config part is a bit more tricky. I assume you invoke this from some higher-level automation scripts? Could that part write the json.

[hogander-unikie]

I think we should improve syz-bisect interface instead. I don't see this providing significant additional value on top of just converting the way things are passed in to syz-bisect. And at the same time it too over-specified for your particular case and does not allow to specify lots of important things (repro.opts, VM type, procs, that http port may be busy, etc). I don't mind if we change syz-bisect -crash flag to a set of separate flags like this script accepts. The way -crash works was just handy for my early experiments. The manager config part is a bit more tricky. I assume you invoke this from some higher-level automation scripts? Could that part write the json.

Currently we don't have any automation for this. This was prepared for our config bisect evaluation and was fastest way to get syz-bisect to run for wanted reproducers without manually generating all these files syz-bisect requires (my lack of experience in Golang might play role in this). Currently I'm running something like this:

for i in $reproducers; do ./bisect.py --reproducer linux/$i.c --kernel_repository ~/work/linux --kernel_branch v4.19.108 --chroot ./chroot --baseline_config ./baseline --reproducer_config ./upstream-leak.config --bisect_bin ./bisect_bin --syzkaller_repository ~/go/src/github.com/google/syzkaller --output ./out; mv ./out/syz-bisect.log ./out/$i.log; done

It's pretty easy to repeat by anyone compared to syz-bisect current interface. Yes, another option is to change syz-bisect interface.

[dvyukov]

(my lack of experience in Golang might play role in this).

I think we should improve syz-bisect interface instead. I don't see this providing significant additional value on top of just converting the way things are passed in to syz-bisect. And at the same time it too over-specified for your particular case and does not allow to specify lots of important things (repro.opts, VM type, procs, that http port may be busy, etc). I don't mind if we change syz-bisect -crash flag to a set of separate flags like this script accepts. The way -crash works was just handy for my early experiments. The manager config part is a bit more tricky. I assume you invoke this from some higher-level automation scripts? Could that part write the json.

Currently we don't have any automation for this. This was prepared for our config bisect evaluation and was fastest way to get syz-bisect to run for wanted reproducers without manually generating all these files syz-bisect requires (my lack of experience in Golang might play role in this). Currently I'm running something like this:

for i in $reproducers; do ./bisect.py --reproducer linux/$i.c --kernel_repository ~/work/linux --kernel_branch v4.19.108 --chroot ./chroot --baseline_config ./baseline --reproducer_config ./upstream-leak.config --bisect_bin ./bisect_bin --syzkaller_repository ~/go/src/github.com/google/syzkaller --output ./out; mv ./out/syz-bisect.log ./out/$i.log; done

It's pretty easy to repeat by anyone compared to syz-bisect current interface. Yes, another option is to change syz-bisect interface.

I see. My concern is that it feels too ad-hoc, it does not allow to specify some things, some thing it's doing wrongly (in general, may be was fine in you single context), it also uses programming language different from the rest of syzkaller (and that I am personally not very proficient with, so I can't maintain it) and it redoes the interface I did in the other repo (which is kinda, why did we do it wrongly in the first place?). I see 2 possible ways forward: (1) either you keep it as is on your side (check in into your github repo, I don't mind adding a link in this repo and/or syzkaller), (2) or we do something more coherent, without redoing interfaces, in a single language, without hardcoded things tailored to a single context, etc.