LWN: Comments on "On-disk format robustness requirements for new filesystems"

On-disk format robustness requirements for new filesystems

Trammael — Tue, 26 Nov 2019 03:31:07 +0000

>Somewhere out there Hans Reiser cries loudly.

California Dept of Corrections, Correctional Training Facility, Soledad Prison Road, Soledad, CA

On-disk format robustness requirements for new filesystems

hsiangkao — Mon, 09 Sep 2019 02:08:23 +0000

In the first RFC patch last year, it was written in Extendable Read-Only File System suggested by some colleague.
I'd prefer the original name Enhanced Read-Only File System though, so change back again...
maybe full name is not important though..

On-disk format robustness requirements for new filesystems

polyp — Thu, 05 Sep 2019 13:46:52 +0000

EROFS apparently stands for Enhanced Read-Only File System, not Extendable.

On-disk format robustness requirements for new filesystems

holgerschurig — Wed, 04 Sep 2019 06:42:27 +0000

> Maybe it helps Huawei,

I think you think too short.

Some of the android things are too specific for android. But some of the concepts needed there are also things that you need in other problem domains (e.g. embedded). And if EROFS is in Linux, then other projects (often in Embedded) might use it as well. It might actually already in use today :-)

> or at least bug reports for existing filesystems.

They are. Hellwig said for XFS that they make great strides for the v5 version, T'so said that for ext4 they work on this, just not with high priority. So warm up your fuzzer and start submitting bug reports :-)

On-disk format robustness requirements for new filesystems

eduard.munteanu — Sat, 31 Aug 2019 13:17:19 +0000

I recently discovered one can craft FAT32 filesystems containing filenames which break POSIX guarantees, and they'll be gladly accepted by the Linux driver. For instance, you can get a file named ../../dev/sda that'll break just about every userspace tool acting on it. And no, that's not even a symlink, so typical countermeasures will fail to reject it. Imagine mounting that from a USB drive into /mnt/stick and something privileged comes along writing into /mnt/stick/../../dev/sda, because it totally looks like a regular file.

On-disk format robustness requirements for new filesystems

pabs — Sun, 25 Aug 2019 01:04:10 +0000

Is lklfuse merged into mainline Linux yet?

On-disk format robustness requirements for new filesystems

hsiangkao — Sat, 24 Aug 2019 19:04:57 +0000

> If a user plugs a USB drive in his/her machine and it causes the machine to lock up because it has a broken EROFS filesystem on it, that's not cool.

We think that's not cool as well, so we are now addressing and will continue actively addressing it.
But that is not absolute standard on this field ---- one hour, two hours, a day, a month, or forever? by some tool? and that is not filesystem-specific issue, but for all on-disk new features...

Again, please give us some time, not long before it resists almost all malformed images (it can already resist more malformed images than weeks before, and we will fix those reports as quick as what we can... that is our attitude on this...)

On-disk format robustness requirements for new filesystems

alonz — Sat, 24 Aug 2019 17:45:12 +0000

One could argue that the behavior of mount(8) (automatically trying all filesystem types) is the actual bug, and that its "auto" mode should restrict itself to using filesystems that are actually suitable for use with the current media. (Many filesystem types, EROFS included, could then be defined as supported only on non-removable media by default.)

Alternatively, the filesystem driver may itself verify that the media type is suitable before even reading the superblock.

(Personally I would love it if we could just use lklfuse for all filesystems on removable media… But it looks like nobody support it.)

On-disk format robustness requirements for new filesystems

buck — Sat, 24 Aug 2019 06:12:21 +0000

> As for "That's the only way to get the average quality up.", who cares? Maybe it helps Huawei, or maybe not, but making EROFS better doesn't make Linux better for all the users out there who aren't running EROFS.

If a user plugs a USB drive in his/her machine and it causes the machine to lock up because it has a broken EROFS filesystem on it, that's not cool. It may not be fair, but there's an argument that can be made for not allowing in additional filesystems that widen the gamut of such problems.

That said, i've never written code for a filesystem or anything else nearly as complex that's supposed to deliver as much functionality, so, yes, i can imagine it may put an unrealistic damper on the possibilities for future awesomeness. I'll trust the LKML arbiters to figure it out.

On-disk format robustness requirements for new filesystems

k8to — Fri, 23 Aug 2019 19:42:28 +0000

Perhaps it makes sense for replacement calls that have shown a lot of pressure over time?

But globally it seems burdensome.

On-disk format robustness requirements for new filesystems

mina86 — Thu, 22 Aug 2019 11:35:24 +0000

To rephrase, it’s unfair to demand that new system calls have a “flags” field which allow for painless future expansion because existing system calls often lack that field.

On-disk format robustness requirements for new filesystems

dgc — Wed, 21 Aug 2019 08:18:30 +0000

There are a *lot* of fuzzing tests for XFS in xfstests:

$ git grep fuzz tests/xfs/group |wc -l
156
$

156 separate on-disk format fuzzing tests, quite a few (~40) of which also test the ability of the under-development online repair code to fix the fuzzing damage automatically. These fuzzers know the on-disk format, so they defeat all the CRC checking by recalculating the CRC after the structures have been corrupted. That's why we have our own fuzzers - at the time nobody had a fuzzer capable of defeating CRCs, so we extended our own tools to do it....

So the truth is that XFS developers have a very high standard for on-disk format robustness and we have both the toolchain and runtime verification in place to find and fix bugs and areas we don't validate as well as we should. It's an ongoing process of improvement....

-Dave.

On-disk format robustness requirements for new filesystems

dvdeug — Wed, 21 Aug 2019 06:20:20 +0000

At its worst, it could mean a lack of new filesystems, because they were all held to unrealistic standards, and the current filesystems all bitrotten out, because it's just expected they aren't robust.

Again, for "That's the only way to get the average quality up", this does not seem to be a viable way to get the average quality of Linux up for most users.

On-disk format robustness requirements for new filesystems

rsidd — Wed, 21 Aug 2019 05:56:26 +0000

Tux3's author never submitted it for upstreaming, AFAIK. In 2018 he said "For the time being we will continue to develop out-of-tree". There seem to be no updates after that.

AFL for filesystems, fsfuzzer

sitsofe — Tue, 20 Aug 2019 21:17:25 +0000

Yes, people have built fuzzers for filesystem images (there are even more if you mean things like syscalls - see fsx, trinity, syzkaller etc). Several years ago an Oracle developer applied afl to a number of different filesystem images and found bugs could be triggered within a few minutes of fuzing (but I don't know if the code for this was ever released). Going back further, the month of kernel bugs introduced the fsfuzzer back in 2006.

On-disk format robustness requirements for new filesystems

Freeaqingme — Tue, 20 Aug 2019 11:06:16 +0000

Are there any fuzzing projects specifically for file systems? This seems like a perfect candidate for fuzzing(?).

On-disk format robustness requirements for new filesystems

kmeyer — Tue, 20 Aug 2019 10:19:38 +0000

Tux3? Bcachefs? Linux has a long tradition of this.

On-disk format robustness requirements for new filesystems

tao — Tue, 20 Aug 2019 09:57:40 +0000

I have a hard time accepting the "It's unfair to expect better of new contributions than of pre-existing code (paraphrasing here)" argument.

Pre-existing file-system code can be hard to fix because a.) it might necessitate breaking on-disk format, which is usually a no-go, b.) regressions have a real-world impact.

Ensuring a high level of robustness on the get-go before merging rather than trying to fix it afterwards is practically guaranteeing that these issues won't ever get fixed.

TL;DR: I totally agree with Christoph Hellwig.

On-disk format robustness requirements for new filesystems

hsiangkao — Tue, 20 Aug 2019 08:11:14 +0000

You can see some prerequisite commits:
https://android-review.googlesource.com/c/platform/system...

and there are some Android commits mentioned about this staging EROFS:
https://android-review.googlesource.com/c/kernel/configs/...

We'd like to upstream to AOSP, and gain wider use of course.

On-disk format robustness requirements for new filesystems

hsiangkao — Tue, 20 Aug 2019 08:05:32 +0000

We will definitely upstream to AOSP as well.

On-disk format robustness requirements for new filesystems

rsidd — Tue, 20 Aug 2019 07:52:15 +0000

I think this is important. If the FS is important for Android, yes, it should be upstreamed. Is there interest from the larger Android community? Are they pushing for upstreaming? If it is only for Huawei's particular fork of Android, why should it be upstreamed?

On-disk format robustness requirements for new filesystems

post-factum — Tue, 20 Aug 2019 06:15:42 +0000

> There seems to be a very unfortunate tendency for us to hold new file systems to impossibly high standards

Somewhere out there Hans Reiser cries loudly.

On-disk format robustness requirements for new filesystems

dvdeug — Tue, 20 Aug 2019 03:55:56 +0000

As for "That's the only way to get the average quality up.", who cares? Maybe it helps Huawei, or maybe not, but making EROFS better doesn't make Linux better for all the users out there who aren't running EROFS. This can work for replacing core parts or even primary filesystems like EXT2 to EXT3 to EXT4, but increasing the average quality by insisting that new filesystems and drivers be better then the ones that are used by most users does little service to most users.

Yes, it's a volunteer system. But if you're concerned about Linux filesystem quality, I'm sure they'll take patches or at least bug reports for existing filesystems. You can push for better quality in core features without taking it out on the new features.