<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 30, 2015 at 1:09 PM, Greg Stark <span dir="ltr"><<a href="mailto:stark@mit.edu" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=stark@mit.edu&cc=&bcc=&su=&body=','_blank');return false;">stark@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><p dir="ltr"><br>
On 30 Aug 2015 20:04, "Kostya Serebryany" <<a href="mailto:kcc@google.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=kcc@google.com&cc=&bcc=&su=&body=','_blank');return false;">kcc@google.com</a>> wrote:<br>
><br>
><br>
> In my (biased) opinion libFuzzer is particularly well suited for this task<br>
> (fuzzing individual libraries, as opposed to fuzzing the whole postgress).<br>
> I've played with a dozen of regular expression libs and found bugs in all of them<br>
> (e.g. search for "Fuzzer" in <a href="http://vcs.pcre.org/pcre2/code/trunk/ChangeLog?view=markup&pathrev=360" target="_blank">http://vcs.pcre.org/pcre2/code/trunk/ChangeLog?view=markup&pathrev=360</a>)<br>
>  <br>
><br>
>>><br>
>>> To do this effectively I think it would be best to invoke the fuzzer<br>
>>> from inside Postgres.<br>
><br>
><br>
> Never tied this. <br>
> Can't you just link libFuzzer with a part of the code you want to test? </p>
</span><p dir="ltr">The problem I'm specifically trying to tackle is that the code in question can use any of the internal postgres APIs and might have dependencies on anything in the environment.</p>
<p dir="ltr">Even the simplest cases like the date/tone parser will depends on the timezone library which is initialised at startup, the server session state which specifies the current timezone and default date format, etc. </p>
<p dir="ltr">The more interesting cases like arrays and other compound objects will depend on the internal caches of the database schema which is where it finds things like meta information about the data types stored within.</p>
</blockquote></div>I see.</div><div class="gmail_extra">At least one of the users of Sanitizer Coverage did something similar with their server, </div><div class="gmail_extra">but they implemented their own mutator/fuzzer (did not use libFuzzer). </div><div class="gmail_extra"><br></div><div class="gmail_extra">With libFuzzer you can't do that today because it expects to receive the coverage feedback from the same process. </div><div class="gmail_extra">With somewhat modification you probably can achieve this: </div>in Fuzzer::RunOneMaximizeTotalCoverage replace the calls to __sanitizer_get_total_unique_coverage<div class="gmail_extra">with something that gets this value for the server process. </div><div class="gmail_extra"><a href="https://github.com/llvm-mirror/llvm/blob/master/lib/Fuzzer/FuzzerLoop.cpp#L231">https://github.com/llvm-mirror/llvm/blob/master/lib/Fuzzer/FuzzerLoop.cpp#L231</a> </div><div class="gmail_extra">Similarly, for the 8-bit counters (-use_counters=1), in the server process call</div>__sanitizer_update_counter_bitset_and_clear_counters and pass the result to the client app. <div><br></div><div>If you can may the change general enough the patch would be more than welcome. <br><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div></div>