Messages in this thread | | | Date | Wed, 17 Jan 2018 15:47:35 -0500 | From | Theodore Ts'o <> | Subject | Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run |
| |
On Wed, Jan 17, 2018 at 12:09:18PM +0100, Dmitry Vyukov wrote: > On Wed, Jan 17, 2018 at 10:49 AM, Daniel Borkmann <daniel@iogearbox.net> wrote: > > Don't know if there's such a possibility, but it would be nice if we could > > target fuzzing for specific subsystems in related subtrees directly (e.g. > > for bpf in bpf and bpf-next trees as one example). Dmitry? > > Hi Daniel, > > It's doable. > Let's start with one bpf tree. Will it be bpf or bpf-next? Which one > contains more ongoing work? What's the exact git repo address/branch, > so that I don't second guess?
As a suggestion, until the bpf subsystem is free from problems that can be found by Syzkaller in Linus's upstream tree, maybe it's not worth trying to test individual subsystem trees such as the bpf tree? After all, there's no point trying to bisect our way checking to see if the problem is with a newly added commit in a development tree, if it turns out the problem was first introduced years ago in the 4.1 or 3.19 timeframe.
After all, finding these older problems is going to have much higher value, since these are the sorts of potential security problems that are worth backporting to real device kernels for Android/ChromeOS, and for enterprise distro kernels. So from an "impact to the industry" perspective, focusing on Linus's tree is going to be far more productive. That's a win for the community, and it's a win for those people on the Syzkaller team who might be going up for promo or listing their achievements at performance review time. :-)
This will also give the Syzkaller team more time to make the automation more intelligent in terms of being able to do the automatic bisection to find the first guilty commit, labelling the report with the specific subsystem tree that that it came from, etc., etc.
Cheers,
- Ted
P.S. Something that might be *really* interesting is for those cases where Syzkaller can find a repro, to test that repro on various stable 4.4, 4.9, 3.18, et. al. LTS kernels. This will take less resources than a full bisection, but it will add real value since knowledge that it will trigger on a LTS kernel will help prioritize which reports developers might be more interested in focusing upon, and it will give them a head start in determining which fixes needed to be backported to which stable kernels.
| |