On Sat, May 26, 2018 at 10:24 PM, Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > 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. These can't be weaponized to execute code, but if a BUG_ON is triggerable over a network, or from VM guest, then it's likely more critical than a local code execution. That's why I am saying that automated evaluation is infeasible. Anyway, bug type (UAF, BUG, task hung) is available in the bug title on dashboard and on mailing lists, so you can just search/sort bugs on the dashboard. What other interface you want on top of this? >> > 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 This was always available in the Repro column. > * Which subsystems the bug has been tentatively assigned > * A maintainer assigned priority and severity level Let's call this tags collectively (unless you have a better name). P0 or subsystem:ext4 can also be tags. So you mean: (1) priority levels (P0, P1, P2), (2) severity levels (S0, S1, S2) and subsystem, right? On a related note, perhaps kernel community needs to finally start using bugzilla for real, like with priorities, assignees, up-to-date statuses, no stale bugs, etc. All of this is available in bug tracking systems for decades... -- 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
