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. Hm. Maybe this is a topic for kernel-summit?
