Adding Daniel Axtens, Lidong and Nils... On Thu, Feb 27, 2025 at 01:22:15PM -0500, Andrew Hamilton wrote: > Hello, > > I’m looking for feedback on whether there would be project interest / support > on me creating an initial fuzz test suite for some core GRUB functions and > then > integrating these fuzzers into the OSS-Fuzz project that would run them and > automate bug reporting to project owners / maintainers on some predefined > periodic basis. > https://github.com/google/oss-fuzz > > Fuzzing helps find program correctness issues like out of bounds accesses, use > after free, crashes, etc. that can sometimes be used for malicious purposes. > > To get a sense of what a fuzzer suite looks like you could reference an > existing project integrated into oss-fuzz like GNUTLS: > https://gitlab.com/gnutls/gnutls/-/tree/master/fuzz?ref_type=heads > > There is some project setup as well in the oss-fuzz repo similar to: > https://github.com/google/oss-fuzz/tree/master/projects/gnutls > > If there is favorable feedback I would perform the following general steps: > 1. Identify core GRUB functions to fuzz first (likely those usable in lockdown > and seen as most likely to be widely used at first, and that are seen as a > possible source of untrusted input). > 2. In a private fork of GRUB (with core GRUB maintainers invited): > a. Get a fuzz target added to the build system. > b. Implement fuzzers for the core features. > c. Fix issues identified by the fuzzers, if any. > d. Create docs around how to build the fuzzers, run them, and locally > troubleshoot issues > e. Submit patches to the maintainers and (if not sensitive due to uncovered > vulnerabilities) to this mailing list for review. > f. With maintainers support, get the fuzzers merged to GRUB mainline. > 3. Open a new project request in the oss-fuzz repo following their > documentation: > a. > https://github.com/google/oss-fuzz/blob/master/docs/getting-started/accepting_new_projects.md > b. https://google.github.io/oss-fuzz/getting-started/new-project-guide/ > 4. If the project approves I’d be willing to serve as the maintainer of the > fuzzing and oss-fuzz components to ensure build failures are corrected and > newly identified issues are worked and triaged. > 5. Over time we can work to improve code coverage via the fuzzers. > > > Pros: > 1. Increase the code robustness > 2. Quickly find robustness issues caused by future changes > Cons: > 1. Requires up front development to get going- I’m happy to do as much of this > as I can but it will require support from the busy project maintainers for > reviews and such > 2. Requires staying on top of new fuzz failures prior to the oss-fuzz > disclosure deadline (I’m happy to support this as much as I can) - ref > https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/ > > Please let me know your thoughts.
I think this is good idea! May I ask you to work with Daniel Axtens, Lidong and Nils on this? They were or are looking at the GRUB fuzzing. So, it would be good join the forces. I think it would be nice to setup a call when all of you are OK to work on the project... Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
