On Wed, Sep 06, 2023 at 09:06:21AM +1000, Dave Chinner wrote: > I think this completely misses the point of contention of the larger > syzbot vs filesystem discussion: the assertion that "testing via > syzbot means the subsystem is secure" where "secure" means "can be > used safely for operations that involve trust model violations". > > Fundamentally, syzbot does nothing to actually validate the > filesystem is "secure". Fuzzing can only find existing bugs by > simulating an attacker, but it does nothing to address the > underlying issues that allow that attack channel to exist. I don't think anyone makes that assertation. Instead the assumptions is something that is handling untrusted input should be available to surive fuzzing by syzbot, and that's an assumption I agree with. That doesn't imply anything surving syzbot is secure, but it if doesn't survive syzbot it surely can't deal with untrusted input. > > unmaintained. If we want to move the kernel forward by finishing > > API transitions (new mount API, buffer_head removal for the I/O path, > > ->writepage removal, etc) these file systems need to change as well > > and need some kind of testing. The easiest way forward would be > > to remove everything that is not fully maintained, but that would > > remove a lot of useful features. > > Linus has explicitly NACKed that approach. > > https://lore.kernel.org/linux-fsdevel/CAHk-=wg7DSNsHY6tWc=WLeqDBYtXges_12fFk1c+-No+fZ0xYQ@xxxxxxxxxxxxxx/ .. and that is why I'm bring this up in a place where we can have a proper procedural discussion instead of snarky remarks. This is a fundamental problem we;ll need to sort out. > Which is a problem, because historically we've taken code into > the kernel without requiring a maintainer, or the people who > maintained the code have moved on, yet we don't have a policy for > removing code that is slowly bit-rotting to uselessness. ... and we keep merging crap that goes against all established normal requirements when people things it's new and shiny and cool :(
