On Wed, Sep 06, 2023 at 03:32:28PM -0700, Guenter Roeck wrote: > On 8/30/23 07:07, Christoph Hellwig wrote: > > Hi all, > > > > we have a lot of on-disk file system drivers in Linux, which I consider > > a good thing as it allows a lot of interoperability. At the same time > > maintaining them is a burden, and there is a lot expectation on how > > they are maintained. > > > > Part 1: untrusted file systems > > > > There has been a lot of syzbot fuzzing using generated file system > > images, which I again consider a very good thing as syzbot is good > > a finding bugs. Unfortunately it also finds a lot of bugs that no > > one is interested in fixing. The reason for that is that file system > > maintainers only consider a tiny subset of the file system drivers, > > and for some of them a subset of the format options to be trusted vs > > untrusted input. It thus is not just a waste of time for syzbot itself, > > but even more so for the maintainers to report fuzzing bugs in other > > implementations. > > > > What can we do to only mark certain file systems (and format options) > > as trusted on untrusted input and remove a lot of the current tension > > and make everyone work more efficiently? Note that this isn't even > > getting into really trusted on-disk formats, which is a security > > discussion on it's own, but just into formats where the maintainers > > are interested in dealing with fuzzed images. > > > > Part 2: unmaintained file systems > > > > A lot of our file system drivers are either de facto or formally > > 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. > > > > E.g. the hfsplus driver is unmaintained despite collecting odd fixes. > > It collects odd fixes because it is really useful for interoperating > > with MacOS and it would be a pity to remove it. At the same time > > it is impossible to test changes to hfsplus sanely as there is no > > mkfs.hfsplus or fsck.hfsplus available for Linux. We used to have > > one that was ported from the open source Darwin code drops, and > > I managed to get xfstests to run on hfsplus with them, but this > > old version doesn't compile on any modern Linux distribution and > > new versions of the code aren't trivially portable to Linux. > > > > Do we have volunteers with old enough distros that we can list as > > testers for this code? Do we have any other way to proceed? > > > > If we don't, are we just going to untested API changes to these > > code bases, or keep the old APIs around forever? > > > > In this context, it might be worthwhile trying to determine if and when > to call a file system broken. > > Case in point: After this e-mail, I tried playing with a few file systems. > The most interesting exercise was with ntfsv3. > Create it, mount it, copy a few files onto it, remove some of them, repeat. > A script doing that only takes a few seconds to corrupt the file system. > Trying to unmount it with the current upstream typically results in > a backtrace and/or crash. Did you forget to take the checksum after copying and verifying it when remounting the fs? Thanks. -- An old man doll... just what I always wanted! - Clara
Attachment:
signature.asc
Description: PGP signature
