> On Feb 28, 2025, at 7:57 AM, Andrew Hamilton <adham...@gmail.com> wrote: > > Yes that sounds great, I am back from vacation just now so will be generally > free any time between 0800 and 2100 Central Standard Time.
I’m mostly available from 9am PT onward. Thanks, Lidong > > Thanks, > Andrew > On Fri, Feb 28, 2025 at 7:33 AM Daniel Kiper <daniel.ki...@oracle.com> wrote: > 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
