On Sun, Aug 13, 2023 at 04:08:58AM +0100, Matthew Wilcox wrote:
> On Sat, Aug 12, 2023 at 07:06:47PM -0400, Theodore Ts'o wrote:
> > One could say that this is an insane threat model, but the syzbot team
> > thinks that this can be used to break out of a kernel lockdown after a
> > UEFI secure boot. Which is fine, except I don't think I've been able
> > to get any company (including Google) to pay for headcount to fix
> > problems like this, and the unremitting stream of these sorts of
> > syzbot reports have already caused one major file system developer to
> > burn out and step down.
> >
> > So problems like this get fixed on my own time, and when I have some
> > free time. And if we "simplify" the code, it will inevitably cause
> > more syzbot reports, which I will then have to ignore, and the syzbot
> > team will write more "kernel security disaster" slide deck
> > presentations to senior VP's, although I'll note this has never
> > resulted in my getting any additional SWE's to help me fix the
> > problem...
> >
> > > So just __ext4_iget() needs to be fixed. I think we should consider doing that
> > > before further entrenching all the extra ->s_encoding checks.
> >
> > If we can get an upstream kernel consensus that syzbot reports caused
> > by writing to a mounted file system aren't important, and we can
> > publish this somewhere where hopefully the syzbot team will pay
> > attention to it, sure...
>
> What the syzbot team don't seem to understand is that more bug reports
> aren't better. I used to investigate one most days, but the onslaught is
> relentless and I just ignore syzbot reports now. I appreciate maintainers
> don't necessarily get that privilege.
>
> They seem motivated to find new and exciting ways to break the kernel
> without realising that they're sapping the will to work on the bugs that
> we already have.
>
Well, one thing that the kernel community can do to make things better is
identify when a large number of bug reports are caused by a single issue
("userspace can write to mounted block devices"), and do something about that
underlying issue (https://lore.kernel.org/r/20230704122727.17096-1-jack@xxxxxxx)
instead of trying to "fix" large numbers of individual "bugs". We can have 1000
bugs or 1 bug, it is actually our choice in this case.
- Eric
