diff options
| -rw-r--r-- | gsoc.html | 207 |
1 files changed, 200 insertions, 7 deletions
@@ -63,14 +63,178 @@ <dl> <dt>Improve fuzzing for FreeType</dt> <dd> - <p>Description will follow.</p> - - <p><em>Difficulty: </em>medium. <em>Requirements:</em> - C, C++, Unix build tools. <em>Potential mentors:</em> - Kostya Serebryany (Google), Werner Lemberg - (FreeType).</p> + <p>There are at least two fuzzers that constantly test + FreeType. One of them + is <a href="https://github.com/google/oss-fuzz">OSS-Fuzz</a>, + and the tasks for GSoC presented here are targeted to + increase the efficiency of this fuzzer bot.</p> + + <dl> + <dt>Split the existing fuzz target into many</dt> + <dd> + <p>Right now we + have <code>src/tools/ftfuzzer/ftfuzzer.cc</code> + that contains</p> + + <pre> +extern "C" +int LLVMFuzzerTestOneInput(const uint8_t* data, + size_t size_) +{ + ParseWhateverFontFileIGet(data, size); +}</pre> + + <p>Instead of this monolithic approach we should + split fuzzing into separate files (fuzz targets) + for every font format, for example</p> + + <pre> +src/tools/ftfuzzer/cff_fuzz.cc +src/tools/ftfuzzer/cff2_fuzz.cc +src/tools/ftfuzzer/cid_fuzz.cc</pre> + + <p>and every such file will have</p> + + <pre> +extern "C" +int LLVMFuzzerTestOneInput(const uint8_t* data, + size_t size_) +{ + ParseOnlyMyFormatAndRejectAnythingElseQuickly(data, size); +}</pre> + + <p>Ideally, the build rule for <code>cff_fuzz</code> + will not <em>link</em> anything that CFF does not + need.</p> + + <p>Such a split will make fuzzing more efficient for + many reasons.</p> + + <ul> + <li>Genetic mutations will not spend time crossing + over files of different formats (e.g., trying to + add BDF genes to a Type 1 font).</li> + <li>Data-flow guided mutations will not try to + transform, say, a CID font file into a PCF font + file.</li> + <li>Some of the fuzzer's internal algorithms that + are linear by the code size will run faster.</li> + <li>Slow inputs that currently make fuzzing + inefficient will cause only some of the targets + suffer, not all of them.</li> + </ul> + + <p>The changes will need to be reflected in the + <a href="https://github.com/google/oss-fuzz/tree/master/projects/freetype2">OSS-Fuzz + repository</a>.</p> + + <p><em>Difficulty: </em>medium. <em>Requirements:</em> + C, C++, Unix build tools. <em>Potential + mentors:</em> Kostya Serebryany (Google), Werner + Lemberg (FreeType).</p> + </dd> + </dl> + + <dl> + <dt>Prepare a public corpus of inputs</dt> + <dd> + <p>The quality of the ‘seed corpus’ is + the key to fuzzing efficiency. We should set up a + repository (e.g., in github) that would hold</p> + + <ul> + <li><em>small</em> but representative sample font + files for every relevant font format (only with + permissive licenses!), and</li> + <li>fuzzed mutations of the above (this part will + need to be periodically updated as fuzzing finds + more inputs).</li> + </ul> + + <p>This corpus will be used in two ways, namely</p> + + <ul> + <li>to seed the fuzzing process, and</li> + <li>as a regression suite (see below).</li> + </ul> + + <p><em>Difficulty: </em>medium. <em>Requirements:</em> + Unix build tools, experience with + scripting. <em>Potential mentors:</em> Kostya + Serebryany (Google), Werner Lemberg + (FreeType).</p> + </dd> + </dl> + + <dl> + <dt>Extend the FreeType testing process to use the + above corpus</dt> + <dd> + <p>The public corpus will allow us to use the fuzz + targets as a regression test suite. We'll need to + set up a continuous integration testing (not + fuzzing) to run the fuzz targets on the corpus. + One way to achieve it is to have a github mirror + of FreeType and set up Travis (or whatever other + CI integrated with github).</p> + + <p><em>Difficulty: </em>medium. <em>Requirements:</em> + Unix build tools, experience with + scripting. <em>Potential mentors:</em> Kostya + Serebryany (Google), Werner Lemberg + (FreeType).</p> + </dd> + </dl> + + <dl> + <dt>Analyze code coverage</dt> + <dd> + <p>Once the fuzz targets are split, the public + corpus is prepared, and the OSS-Fuzz integration + is updated, we'll need to analyze + the <a href="https://github.com/google/oss-fuzz/blob/master/docs/clusterfuzz.md#coverage-reports">code + coverage provided by OSS-Fuzz</a> to see what code + is left untested.</p> + + <p>Then either the fuzz targets or the corpus (or + both) will need to be extended to cover that code. + The ideal end state is to have 100% line coverage + (currently, we have ~67% for the existing fuzz + target).</p> + + <p><em>Difficulty: </em>medium. <em>Requirements:</em> + C, C++, Unix build tools, experience with + scripting. <em>Potential mentors:</em> Kostya + Serebryany (Google), Werner Lemberg + (FreeType).</p> + </dd> + </dl> + + <dl> + <dt>Prepare fuzzing dictionaries for the font formats + where relevant</dt> + <dd> + <p>In some cases a simple dictionary (list of tokens + used by the file format) may + have <a href="http://libfuzzer.info/#dictionaries">dramatic + effect on fuzzing</a>.</p> + + <p><em>Difficulty: </em>easy. <em>Requirements:</em> + Unix build tools, experience with + scripting. <em>Potential mentors:</em> Kostya + Serebryany (Google), Werner Lemberg + (FreeType).</p> + </dd> + </dl> + + <p>While the subtasks themselves are quite isolated, the + order they have to be handled is from top to bottom as + shown in the descriptions above. Consequently, the + project is suited to a group of students also that + work tightly together as a team.</p> </dd> </dl> + <dl> <dt>Develop a test framework for checking FreeType's rendering output</dt> @@ -103,6 +267,35 @@ </dd> </dl> + <dl> + <dt>Improve the ‘ftinspect’ demo program</dt> + <dd> + <p>Right now, FreeType comes with a suite of small + graphic tools to test the library, most notably + ‘ftview’ and ‘ftgrid’. The + used graphics library, while working more or less, is + very archaic, not having any comfort that modern GUIs + are providing.</p> + + <p>To improve this, a new demo program called + ‘ftinspect’ was started, based on the Qt + GUI toolkit. However, the development is currently + stalled, mainly for lack of time.</p> + + <p>The idea is to finish ftinspect, + handling <em>all</em> aspects of the other demo + programs. Currently, it only provides the + functionality of ‘ftgrid’.</p> + + <p>If the student prefers, the Qt toolkit could be + replaced with GTK.<p> + + <p><em>Difficulty:</em> medium. <em>Requirements:</em> + C, C++, Qt, Unix build tools. <em>Potential + mentor:</em> Werner Lemberg (FreeType).</p> + </dd> + </dl> + <p>Do you have more ideas? Please write to our <a href="mailto:freetype-devel@nongnu.org">mailing list</a> so that we can discuss your suggestions, @@ -112,7 +305,7 @@ <!-- ************************************************** --> <div class="updated"> - <p>Last update: 2-Feb-2017</p> + <p>Last update: 3-Feb-2017</p> </div> </div> </div> |