On Tue, Feb 06, 2024 at 01:46:28PM +0100, Florian Weimer wrote: > * Richard W. M. Jones: > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=113035034 > > https://bugzilla.redhat.com/show_bug.cgi?id=2262539 > > > > The new AFL++ (American Fuzzy Lop, a fuzzing tool) in Rawhide appears > > to be building a GCC plugin, contained in one or all of these newly > > added files: > > > > %global afl_helper_path %{_libdir}/afl > > %{_bindir}/afl-gcc-fast > > %{_bindir}/afl-g++-fast > > %{afl_helper_path}/afl-gcc-cmplog-pass.so > > %{afl_helper_path}/afl-gcc-cmptrs-pass.so > > %{afl_helper_path}/afl-gcc-pass.so > > %{afl_helper_path}/afl-gcc-rt.o > > %{afl_helper_path}/injection-pass.so > > > > I'm going to guess this will introduce a dependency on the exact > > version of GCC (major only? or major.minor? not sure). Just like > > annobin. Which might require that this package is rebuilt when GCC is > > rebuilt (only major? or all rebuilds? again, don't know). > > It depends on what the plugin does. Not all plugins are as sensitive to > e.g. GCC options changes. A precise NVR dependency might still make > sense. It's easier to pull off here because there's no cyclic > dependency issue. So I don't know how it works precisely, but this is my understanding of what this all does ... For fuzzing we want to produce an instrumented binary which, when run on an input, traces the sequences of branches (ie. paths / basic blocks) taken through the instrumented code. The aim of the fuzzer is to find new inputs which explore new paths in the code, until a crash is found. One way that AFL has done this traditionally is with an assembler wrapper which munges the assembly output of the compiler, searching and replacing branches with instrumentation code. However this is obviously very compiler / architecture specific. In particular AFL only implements this for GCC + x86_64, GCC + i686 (support dropped recently, apparently by accident), and macOS + arm64. AIUI the GCC (also LLVM) plugins replace this with some compiler internal munging instead. One advantage of this is it's not architecture dependent any more, although we don't yet use this in Fedora. Also the compiler plugin is supposed to be faster. However I have not been troubled by the compilation speed of AFL. And AIUI it makes no difference to the run time speed of the binary, which is where faster speed would really make the difference for fuzzing. All of the above is based on my possibly faulty understanding. Any errors are yours to keep. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
