<div dir="ltr"><div dir="ltr">Hi Mark Leon! </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 26, 2020 at 1:54 AM Giraud, Mark Leon via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div id="gmail-m_-2531609975729615965divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>Hello fellow developers,</p>
<p><br>
</p>
<p>I'm currently working on my master thesis with stateful fuzzing of server and embedded software as topic (Aflnet for example fuzzes server software. I'm looking for ways to extend and improve their approach).</p>
<p>I have some questions regarding the fuzzer runtime:</p>
<p><br>
</p>
<ol style="margin-bottom:0px;margin-top:0px">
<li>If i understood the code correctly, there are multiple parts to the instrumentation: The PC tables, the 8 bit counters, and all the comparison hooks. I'm not quite sure what the difference between the pc tables and the 8 bit counters is. Shouldn't the information
of the pc table be contained in the 8 bit counters?</li></ol></div></div></blockquote><div><br></div><div>pc table is a static (immutable) table that maps the 8 bit counters to the PCs. </div><div>8 bit counters are what is actually used to collect the coverage feedback. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_-2531609975729615965divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><ol style="margin-bottom:0px;margin-top:0px"><li>For my planned addition i need to run the callback multiple times, and reset the coverage information (i.e. the pc tables and 8 bit counters?) before each execution, </li></ol></div></div></blockquote><div><br></div><div>8 bit counters.</div><div>libFuzzer resets them after each iteration anyway. <br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_-2531609975729615965divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><ol style="margin-bottom:0px;margin-top:0px"><li>such that i get the coverage that the input produces on its own. Do you have any pointers,
on where to change the fuzzer rt, or would i need to do some additional instrumentation (I'd like to avoid this, since each additional instrumentation pass would mean more code and thus more execution time) in order to not mess with the way the fuzzer works
right now? The optimal case would be that there is one overarching pc table that has the information across runs, and one table that is reset before each run. After the run, the table is then merged into the main table. (I think afl does something like this?)</li></ol></div></div></blockquote><div><br></div><div>libFuzzer also works in a very similar way. </div><div>Check TracePC::CollectFeatures</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_-2531609975729615965divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><ol style="margin-bottom:0px;margin-top:0px"><li>Is there any functionality to set up the target and then fork from that initial state in order to avoid setting up the target each fuzz iteration, or is that not possible, since we are doing in-process fuzzing?</li></ol>
<div><br></div></div></div></blockquote><div><br></div><div>Currently there is no such functionality in libFuzzer. </div><div>Someone recently posted a request to add such, but that's all I know. </div><div><a href="https://groups.google.com/g/libfuzzer/c/7co7dYuiFYk">https://groups.google.com/g/libfuzzer/c/7co7dYuiFYk</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_-2531609975729615965divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><div>
</div>
<div>I'm looking forward to any input on this.</div>
<div><br>
</div>
<div>Best Regards,</div>
<div>Mark<br>
</div>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>