> 
> Makes sense. Sorry if I came off a bit strong, there's been a couple
> syzbot copycats and I find I keep repeating myself :)
> 
> So, it sounds like you're getting nudged to work upstream, i.e. people
> funding you want you to be a bit better engineers so the work you're
> doing is taken up (academics tend to be lousy engineers, and vice
> versa, heh).
> 
> But if you're working on fuzzing, upstream is syzbot, not the kernel -
> if there's a community you should be working with, that's the one.
> 
> An individual bug report like this is pretty low value to me. I see a
> ton of dups, and dups coming from yet another system is downright
> painful.
> 
> The real value is all the infrastructure /around/ running tests and
> finding bugs: ingesting all that data into dashboards so I can look for
> patterns, and additional tooling (like the ktest/syzbot integration, as
> well as other things) for getting the most out of every bug report
> possible.
> 
> If you're working on fuzzing, you don't want to be taking all that on
> solo. That's the power of working with a community :) And more than
> that, we do _very_ much need more community minded people getting
> involved with testing in general, not just fuzzing.
> 


Hi Kent,

Thank you for your insights.

I have a couple of questions I would like to ask for your advice on:

From a testing perspective, we have modified syzkaller and discovered some 
issues. It’s true that researchers working on fuzzing often lack a deep 
understanding of the kernel, making it difficult to precisely determine the 
scope of reported problems. Meanwhile, syzbot provides a description of the 
reporting process (please refer to the link below) and encourages researchers 
to report bugs to maintainers. However, there seems to be a significant gap 
here—researchers may end up reporting bugs to the wrong maintainers or 
submitting reports that lack value. This seems like a serious issue. Could the 
kernel community consider establishing a standardized process to reduce wasted 
time on all sides and prevent researchers from inflating bug counts just to 
validate their papers?

Link: 
https://github.com/google/syzkaller/blob/master/docs/linux/reporting_kernel_bugs.md

It is often suggested that researchers collaborate with syzbot. What should 
such collaboration look like in terms of form and content? From a maintainer's 
perspective, how would you prefer to see researchers who report bugs work with 
syzbot? Since I’m new to this field, I’m not very familiar with the process and 
would greatly appreciate your guidance.

Reply via email to