On Sat, May 26, 2018 at 07:12:49PM +0200, Dmitry Vyukov wrote: > > I don't see that "some kind of machine learning or expert system > evaluation" is feasible. At least not in short/mid-term. There are > innocently-looking bugs that actually turn out to be very bad, and > there are badly looking at first glance bugs that actually not that > bad for some complex reasons. Full security assessment is a complex > task and I think stays "human expert area" for now. One can get some > coarse estimation by searching for "use-after-free" and > "out-of-bounds" on the dashboard. If the kernel intentionally triggers a BUG_ON or a panic (as in file systems configured with 'tune2fs -e panic') it's pretty obvious that those errors can't be weaponized to execute code chosen by the attacker. Would you agree with that? The same should be true for "blocked for more than 120 seconds"; again, I claim that those sorts of errors are by definition less serious than buffer overruns. So there is at least some kind of automated evaluation that can be done, even if the general case problem is really hard. > > Or maybe it would be useful if there was a way where maintainers could > > be able to annotate bugs with priority and severity levels, and maybe > > make comments that can be viewed from the Syzbot dashboard UI. > > This looks more realistic. +Tetsuo proposed something similar: > https://github.com/google/syzkaller/issues/608 > > I think to make it useful we need to settle on some small set of > well-defined tags for bugs that we can show on the dashboard. > Arbitrary detailed free-form comments can be left on the mailing list > threads that are always referenced from the dashboard. > > What tags would you use today for existing bugs? One would be > "security-critical", right? For me, it's not about tags. Things missing from the https://syzkaller.appspot.com/ front page are: * Whether or not a repro is available * Which subsystems the bug has been tentatively assigned * A maintainer assigned priority and severity level I generally don't use the syzkaller.apptspot.com front page because it's too hard to find the sorts of thing that I'm looking for --- namely the most important syzkaller bug that I as an ext4 expert can work on. If someone else sends me a well-formed bug report on bugzilla.kernel.org, with free-standing image file, and a simple .c reproducer, I can make forward progress much more quickly. So if I'm time bound, guess which bug I'm going to pay attention to first? Especially when Syzkaller makes it hard for me to find the bug again once it ages out of my inbox? > Well, we have KASAN, almost have KMSAN and will have KTSAN in future. > They can detect detect significant portion of bugs that go unnoticed > otherwise. At least this prevents "bad guys" from also using tooling > to cheaply harvest exploits. Systematic use of these tools on browsers > raised exploit costs to $1M+ for a reason. I'll note that browsers also use processes and capsicum to provide security boundaries. This is why David and I have been suggesting solutions like FUSE or running the mount in a guest VM, which can act as an isolation layer. Even if there is a bug in the guest kernel, the blast radius of the bug can be isolated, hopefully to the point where it can be completely contained. It's not an either-or, but a both-and. But the much more important thing is that mangement has to be willing to **fund** bug remediation. That was true for Chrome; it doesn't seem to be as true for the Linux Kernel, for whatever reason. People trying to fix Syzkaller and other fuzzer-found bugs on 20% time, or on the weekends, or as a background activity during low-bandwidth meetings, or as an unfunded mandate that doesn't show up on anyone's quarterly objectives upon which they are graded, is just not going to scale. And if that's the reality, it may very well be that if you want Syzkaller to make more a difference, anything you can do to reduce the human toil needed to investigate a bug is going to be hugely important. And if bug remediation is only going to be funded to a very limited extent, then it's important that the bugs we work on are the highest priority ones, since the lower priority ones *will* have to let slide. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
