张驰斌 via llvm-dev
2021-Mar-25 12:16 UTC
[llvm-dev] 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 发件人: Florian Hahn<mailto:florian_hahn at apple.com> 发送时间: 2021年3月10日 5:22 收件人: Johannes Doerfert<mailto:johannesdoerfert at gmail.com>; 张驰斌<mailto:zhangchb1 at shanghaitech.edu.cn> 抄送: llvm-dev<mailto:llvm-dev at lists.llvm.org>; John Regehr<mailto:regehr at cs.utah.edu> 主题: Re: [llvm-dev] Applying for GSoC 2021(Fuzzing LLVM-IR Passes)> On Mar 8, 2021, at 23:17, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > > Having Alive2 as oracle would certainly be great. > > Some rough ideas that can be worked on in parallel if we have multiple GSoC students: > - mutation rules we know are sound, e.g., remove guarantees, add 1 iteration loops, etc. > - input generation, equivalence checking (alive, partial evaluation, ...) > - fragment extraction from larger codes + input tracking -> reproducer splitting, faster equivalence checking, ... > > We certainly can come up with more things. > > Would either or both of your (or anyone else) be interested in co-mentoring students? > We have multiple interested ones already, even though my project description is lacking any detail. >I’d be happy to help out. Cheers, Florian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210325/b03e8a7a/attachment.html>
Florian Hahn via llvm-dev
2021-Mar-31 08:03 UTC
[llvm-dev] Applying for GSoC 2021(Fuzzing LLVM-IR Passes)
Hi,> On Mar 25, 2021, at 12:16, 张驰斌 <zhangchb1 at shanghaitech.edu.cn> wrote: > > 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 <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.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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210331/bded7675/attachment.html>