@@ -121,7 +121,7 @@ should implement support for at least two common manifest formats, for example:
121121
122122Dedicated test cases should be added to ensure its correctness.
123123
124- ### Complete filesystem feature support for erofs-rs
124+ ### Complete Filesystem Feature Support for erofs-rs
125125
126126Proposed mentors: [ @Dreamacro ] ( https://github.com/Dreamacro ) , Gao Xiang
127127Languages: Rust
@@ -142,7 +142,7 @@ Skills:
142142Proposed mentors: Gao Xiang, Hongbo Li ([ @hb-lee ] ( https://github.com/hb-lee ) )
143143Languages: C
144144Estimated project length: 350 hours
145- Difficulty: medium
145+ Difficulty: hard
146146Skills:
147147 - Proficiency in C programming;
148148 - Experience with file system concepts and operations.
@@ -178,3 +178,39 @@ Key objectives:
178178 - Integrate EROFS with FreeBSD’s VFS, buffer cache, and VM systems;
179179 - Validate correctness and performance using real-world workloads;
180180 - Lay groundwork for future BSD ports (OpenBSD, NetBSD).
181+
182+ ### Advanced Fuzzing and Image Injection for the Kernel and erofs-utils
183+
184+ Proposed mentors: Yifan Zhao, Hongbo Li, Gao Xiang
185+ Languages: C, Go and/or Rust
186+ Estimated project length: 175 hours
187+ Difficulty: medium
188+ Skills:
189+ - Proficiency in C programming;
190+ - Experience with file system concepts and operations;
191+ - Familiarity with fuzzing frameworks (e.g., AFL++, libFuzzer) is a plus.
192+
193+ ** Description**
194+
195+ EROFS aims to be a secure, immutable image-based kernel filesystem by design.
196+ Because its on-disk format contains less redundant metadata and is designed
197+ to tolerate bogus or corrupted values, EROFS behaves differently from generic
198+ writable filesystems. In addition, its immutable design means that all writable
199+ data is copied up (aka copy-on-write) into another local trusted filesystem.
200+ This makes it safer than writing directly to an untrusted and potentially
201+ inconsistent generic writable filesystem.
202+
203+ We pay particular attention to the EROFS core on-disk format. Although the
204+ format design is simple and the implementation (especially for the core format)
205+ is straightforward, it is highly beneficial to develop more advanced tools
206+ alongside the current syzkaller and the existing erofs-utils fuzzer. These tools
207+ will keep the codebase robust and allow us to address random human-introduced
208+ bugs more actively and in time.
209+
210+ The main goal is to implement an advanced fuzzing tool and an image injection
211+ tool. These tools may be easier to implement using go-erofs (Go) or erofs-rs
212+ (Rust), for example. We also intend to enable a new GitHub Actions CI workflow
213+ to perform periodic fuzzing.
214+
215+ This will allow us to maintain the kernel and erofs-utils implementations in
216+ better shape.
0 commit comments