The story begins by introducing our EROFS parser to cargo fuzz

[cgwalters]

💣 🩹 ✔️

[cgwalters]

Ah well, I clearly should have let the fuzzer run longer locally

[cgwalters]

CI / Fuzz smoke test (pull_request)Successful in 5m

🎉

[hsiangkao]

@cgwalters , For this part (erofs: Validate block ranges against image size via Image::inode_blocks()), generally at runtime I don't think it's an issue since users can always interupt this (just because the chunk list is long for example) and the runtime (like the kernel) should add proper signal detection and the system won't be stuck; dsb.blocks is just a indicator for statfs use which is like FUSE.
But I think the dump the whole extent list may be unnecessary for many cases, we should map on demand. Even if it can be dumped, the chunk list can still be valid but the time could be long, so I think we just need to detect such timeout case instead and skip this.
Anyway, but for composefs, of course you could limit the image size or even the total numbers of chunks (because I guess it's just used for the sparse usage) instead.

[cgwalters]

Hi @hsiangkao ! 👋

generally at runtime I don't think it's an issue since users can always interupt this (just because the chunk list is long for example) and the runtime (like the kernel) should add proper signal detection and the system won't be stuck;

Yes, but in order to be very defensive I want to ensure that we (can) parse the EROFS with our memory-safe Rust parser here before giving it to the Linux kernel in general. We have the opportunity to impose a lot of structural constraints that should make it even harder to reach potentially buggy kernel codepaths.

Because this is just metadata, analysis is pretty tractable.

Anyway, but for composefs, of course you could limit the image size instead.

Yes that's now also done in this PR 207eb25#diff-06c4aa3c3f7346814be3b4d6eb9ee179c3ace7d29ba3b54383ab0cc9cab1098cR403

[hsiangkao]

Yes, but in order to be very defensive

I respect your choice but the core format is simple enough from either analysis each on-disk field, and since we're in the AI era, I'm confident that all implemention bugs should be detected by AIs (plus the core format and implemention are not complex).
Also the potential implemention bugs happen all over the kernel, like tcp/ip stacks which parse untrusted formats too, and it's not specific to filesystems; I will finish the security model of EROFS on-disk format, analysing each on-disk field risk, basically I think on-disk sb and on-disk inode metadata is just simply read and directly fed into vfs; directory dirent parsing logic is not complex, I don't get any impression where the on-disk field can cause any risk.

[cgwalters]

since we're in the AI era, I'm confident that all implemention bugs should be detected by AIs (plus the core format and implemention are not complex).

Yeah...AI. 😅 Obviously a lot of this PR itself is heavily generated by OpenCode+Opus but I have to say it's just a combination of exhilarating and exhausting to get 90% good code and have to hunt down carefully the 10% where it just decided to disable the tests or revert a previous commit because conflicts were too hard or re-implement base64 encoding for no reason or even more bizarre things...and this is the stuff that still makes it by enforced subagent reviews.

On the topic of AI and security, well there's a variety of things about there but this "aisle" company is putting out things like https://aisle.com/blog/openssl-stack-overflow-cve-2025-15467-deep-dive

Clearly one can get a lot here out of careful tuning: prompts, provided tools etc.

---

Anyways though obviously there's stuff happening in the EROFS space like the inode sharing where we're kind of iterating towards a similar space in terms of feature set from composefs.

That said, IMO composefs is still a great architecture in terms of splitting the metadata vs data planes (and a story of many storage systems is separating those two things). A cool trick we can do is quickly generate new "images" that are just metadata transformations (think e.g. squashing two container image layers). We need a userspace EROFS parser (and writer) to do things like that.

So I think we'll always have it. Of course, maybe at some point the Linux kernel EROFS impl will get ported to Rust, and these things can share code. That'd be cool. But OTOH it's not that much code.

[hsiangkao]

That said, IMO composefs is still a great architecture in terms of splitting the metadata vs data planes (and a story of many storage systems is separating those two things).

I don't think they are conflict, the core format can be simple enough to contain both cases, just the traditional archive format and/or metadata-only manifests: Of course composefs is useful, no one is really arguing that.

Of course, maybe at some point the Linux kernel EROFS impl will get ported to Rust, and these things can share code.

Just some random thought about this (unrelated to anything): I think in the future of AI, the language is the least important stuff; since it's just a formal expression of the computer program logic, but all bugs can be fixed by AI no matter of stupid memory issues or something.
At that time, I don't think Rust is more useful compared to C (because all code can be reviewed by ai; and AI can generate bugless code from formal on-disk spec for example too) since C is more close to the real architecture. Please don't misinterpret that, I just say a future possibility.

[cgwalters]

OK while not strictly related to this PR originally, but since I am juggling too many and it's getting confusing I pushed some more commits here which start to filter the EROFS parsing even more and rationalize our inlining in dumpfiles etc.