Applying for GSoC 2021(Fuzzing LLVM-IR Passes)

Hi Florian,

It’s been a while since I lasted posted a reply on this mailing list. I’ve been going through code in the FuzzMutate folder and commit https://reviews.llvm.org/D96654 for quite some time now. While the current IRMutator implementation allows for module / function level mutation, only instruction level mutations are implemented, namely instruction injection and deletion, which does not preserve the original semantics of the program. I think the sound mutation rule examples provided by Johannes is something I work on in the summer. Aside from that, do you see any opportunity that D96654 alive2-based fuzzer could be expanded on, or are there anything that you wished to implement but not yet done (because I see the label NOT-TO-BE-MERGED)?

My personal opinion is that it’s pretty feature complete. Any other advice will be helpful too:)

Thanks in advance,

Chibin Zhang

2021.3.25

Hi,

Hi Florian,
       It’s been a while since I lasted posted a reply on this mailing list. I’ve been going through code in the FuzzMutate folder and commit ⚙ D96654 [NOT-TO-BE-MERGED] Add alive2-based fuzzer for quite some time now. While the current IRMutator implementation allows for module / function level mutation, only instruction level mutations are implemented, namely instruction injection and deletion, which does not preserve the original semantics of the program.

Yes, I think the current IR mutators only remove or add a subset of instructions, and can add/drop some flags. They may create programs with different behavior to the corpus, but that’s exactly what makes fuzzing interesting (new code example to test).

I think the sound mutation rule examples provided by Johannes is something I work on in the summer.

Sounds good. As part of the proposal, it would probably be good to expand on what type of soundness you are aiming for (e.g. do not introduce new undefined behavior). I think the challenge will be on how can we make sure to generate the most interesting programs given that constraint. An example of an existing mutator that may introduce UB is the one that adds or removes nuw/nsw to/from existing instructions.

Aside from that, do you see any opportunity that D96654 alive2-based fuzzer could be expanded on, or are there anything that you wished to implement but not yet done (because I see the label NOT-TO-BE-MERGED)?
My personal opinion is that it’s pretty feature complete. Any other advice will be helpful too:)

It’s just a starting point, but the mechanics are actually quite straight forward. The interesting bit is where can we go from there? Things like can we detect if a generated program has UB and reject it as candidate? (To complement the sound-only mutators) Can we create more interesting candidates without introducing a bunch of UB, which makes the inputs much less interesting, especially when verifying a transform with Alive?

Cheers,
Florian