Why ext4? [LWN.net]

Why ext4?

Posted Oct 8, 2020 19:45 UTC (Thu) by Yenya (subscriber, #52846)
Parent article: The ABI status of filesystem formats

There are filesystems which are designed to be read-only, such as ISO9660. Why abuse ext4?

to post comments

Why ext4?

Posted Oct 8, 2020 20:19 UTC (Thu) by sfeam (subscriber, #2841) [Link] (5 responses)

"There are filesystems which are designed to be read-only, such as ISO9660. Why abuse ext4?"

Choosing a different filesystem might lessen Ts'o's personal stake in the push-back but the same general arguments and principles would apply to any filesystem, right? The most solid argument Ts'o raises is that a read-only file system may still be a malware vector if the kernel code handling it fails to consider some edge case or unforeseen content in a data structure. Any patch to fix that vulnerability could hypothetically break an out-of-tree application that had been relying on the previous behavior. Is that to be considered a regression or not? In fact the general argument applies even if the filesystem is not read-only.

Why ext4?

Posted Oct 8, 2020 20:23 UTC (Thu) by Yenya (subscriber, #52846) [Link]

Well, a read-only by-design filesystem would not need a bitmap of free blocks and free inodes. And being able to make the r/only filesystem smaller for the same amount of data makes sense, unlike that abuse of ext4.

Why ext4?

Posted Oct 9, 2020 1:14 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

But that argument even applies to e2fsprogs itself. How do we know there isn't some weird combination of flags you can pass to tune2fs or mke2fs which somehow makes an evil filesystem? At that point, you would have to break e2fsprogs backcompat anyway. This is probably a lot less *likely* than the "some third-party tool generates a weird filesystem image" case, but some of those third-party tools are actually rather popular (e.g. the article mentions FreeBSD), and breaking them would also be unfortunate. So I'm not sure how much sense it makes to draw a bright line around e2fsprogs as the single point of compatibility.

Why ext4?

Posted Oct 9, 2020 3:45 UTC (Fri) by epa (subscriber, #39769) [Link] (2 responses)

ISO 9660 has a standard formally specifying it. That means you can decide whether a given file system image is valid, and if the kernel doesn’t work with a valid image, that is clearly a kernel bug. So no, it doesn’t quite have the same general problem as ext4.

In principle the point still stands: there could be a bug in the kernel code when handling a malformed file system image, and that bug could cause security problems, yet somebody might be relying on the exiting behaviour because they use one of these malformed images. But that seems much less likely with ISO 9660, partly because it’s much simpler than ext4, and partly because it’s understood by many different OSes, so you’d soon find out if your image depended on a Linux-specific quirk.

I have a CD-ROM that’s meant to be in ISO 9660 format but many of the filenames contain the / character. Linux does not handle this well. But it’s clearly incorrect by the standard, so you can say this is no bug in Linux.

Why ext4?

Posted Oct 9, 2020 6:38 UTC (Fri) by Yenya (subscriber, #52846) [Link] (1 responses)

Well, my (rhetorical) question was, why Josh Triplett even decided to use this "optimized" ext4 image instead of going for some filesystem which is read-only by design. Not whether there can arise the same kind of problems with ISO 9660.

Why ext4?

Posted Oct 9, 2020 8:06 UTC (Fri) by epa (subscriber, #39769) [Link]

Yes, I wasn't replying to your comment, but to sfeam's one.

Why ext4?

Posted Oct 9, 2020 12:02 UTC (Fri) by eru (subscriber, #2753) [Link] (5 responses)

>There are filesystems which are designed to be read-only, such as ISO9660. Why abuse ext4?

Maybe he needed a file system that supports all features expected of a native Linux file system. ISO9660 does not qualify. (But squashfs would? It would also automatically save space).

Why ext4?

Posted Oct 11, 2020 21:27 UTC (Sun) by WolfWings (subscriber, #56790) [Link] (3 responses)

SquashFS _requires_ compression, so there'd be a compression -> decompression layer involved. CRAMFS has a ~256MB total size limit. ROMFS is 32-bit so it'd run into obstacles around the 4GB mark (or maybe 2GB, I don't think it's been tested for >2GB total size to my knowledge) but it would be the lightest weight option IMHO.

But this does boil down to they were abusing an invalid filesystem data structure configuration that was not previously checked. That they were declaring that a particular flag marked the filesystem as such a monstrosity doesn't change that they were laying multiple copies of a data structure on top of each other instead of pushing upstream for a proper "read only" flag that did away with those structures entirely is the core invalidity.

Why ext4?

Posted Oct 13, 2020 15:30 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (1 responses)

What about EROFS? It doesn't look very complicated, but it does appear to support most things you might reasonably want to do.

https://www.kernel.org/doc/html/latest/filesystems/erofs....

Why ext4?

Posted Oct 18, 2020 16:19 UTC (Sun) by WolfWings (subscriber, #56790) [Link]

Oh, yup, I'd missed that one going through the main filesystems, that one looks to nail it and he "ROMFS but a full Linux filesystem" so it's just about ideal.

Why ext4?

Posted Oct 20, 2020 5:38 UTC (Tue) by eru (subscriber, #2753) [Link]

Squashfs, unlike cramfs, does not have problematic size limitations: "Files up to 2^64 bytes are supported; file systems can be up to 2^64 bytes" (https://tldp.org/HOWTO/SquashFS-HOWTO/whatis.html).

Why ext4?

Posted Oct 26, 2020 20:57 UTC (Mon) by mina86 (guest, #68442) [Link]

FYI, there’s Rock Ridge extension which adds POSIX semantics to an ISO file-system.