|
|
Log in / Subscribe / Register

Why ext4?

Why ext4?

Posted Oct 8, 2020 20:19 UTC (Thu) by sfeam (subscriber, #2841)
In reply to: Why ext4? by Yenya
Parent article: The ABI status of filesystem formats

"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.


to post comments

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.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds