FYI: AFL++ now builds a GCC plugin

[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).

If this proves to be a problem then I can drop the GCC plugin usage,
or we could work out a process to deal with rebuilding.

Anyway, let's look out for this and see if it causes trouble, and then
decide what to do.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 06 February 2024 at 12:54, Richard W.M. Jones wrote:
>    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 
By the way, I think it makes no sense to define and use afl_helper_path
macro here. %{_libdir}/afl is shorter than %{_afl_helper_path}.

Regards,
Dominik
-- 
Fedora   https://fedoraproject.org
Deep in the human unconscious is a pervasive need for a logical universe that
makes sense. But the real universe is always one step beyond logic.
        -- from "The Sayings of Muad'Dib" by the Princess Irulan

[Jakub Jelinek]

On Tue, Feb 06, 2024 at 11:54:23AM +0000, Richard W.M. Jones wrote:
>    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).
>  
>  If this proves to be a problem then I can drop the GCC plugin usage,
>  or we could work out a process to deal with rebuilding.
>  
>  Anyway, let's look out for this and see if it causes trouble, and then
>  decide what to do. 
Guess it depends on what exactly it uses.
Obviously, there must be a dependency on the major version.  The plugin API
(which is essentilly everything in the compiler) can change obviously at any
time, but in reality on release branches (at least past the major.1 release)
it doesn't change much very often, from the annobin experience the only
major problematic thing are accesses to options - global_options{,_set} and
the like, including through macros like flag_* or opt_for_fn etc.

As described in https://gcc.gnu.org/r11-5149 , annobin has some code to find
out offsets of options in global_options{,_set} etc. even if it has been
built against different version of gcc (same major, but from different
date), where perhaps some options have been added or removed and that in
turn caused reshuffling of options which were there before and are still in
there but at different offsets.

	Jakub

[Richard W.M. Jones]

On Tue, Feb 06, 2024 at 01:23:48PM +0100, Jakub Jelinek wrote:
>  On Tue, Feb 06, 2024 at 11:54:23AM +0000, Richard W.M. Jones wrote:
>  >   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).
>  > 
>  > If this proves to be a problem then I can drop the GCC plugin usage,
>  > or we could work out a process to deal with rebuilding.
>  > 
>  > Anyway, let's look out for this and see if it causes trouble, and then
>  > decide what to do.
>  
>  Guess it depends on what exactly it uses.
>  Obviously, there must be a dependency on the major version.  The plugin API
>  (which is essentilly everything in the compiler) can change obviously at any
>  time, but in reality on release branches (at least past the major.1 release)
>  it doesn't change much very often, from the annobin experience the only
>  major problematic thing are accesses to options - global_options{,_set} and
>  the like, including through macros like flag_* or opt_for_fn etc.
>  
>  As described in https://gcc.gnu.org/r11-5149 , annobin has some code to find
>  out offsets of options in global_options{,_set} etc. even if it has been
>  built against different version of gcc (same major, but from different
>  date), where perhaps some options have been added or removed and that in
>  turn caused reshuffling of options which were there before and are still in
>  there but at different offsets. 
Not sure if it helps but it seems these source files implement the
plugin:

https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/af...
https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/af...
https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/af...

and this header:

https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/af...

At a glance it seems like it uses a lot of APIs ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

[Jakub Jelinek]

On Tue, Feb 06, 2024 at 12:38:31PM +0000, Richard W.M. Jones wrote:
>  Not sure if it helps but it seems these source files implement the
>  plugin:
>  
>
> https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/af...
>
> https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/af...
>
> https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/af...
>  
>  and this header:
>  
>  https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/af...
>  
>  At a glance it seems like it uses a lot of APIs ... 
From quick skimming, I've only noticed
    set_decl_tls_model(
        decl, (flag_pic ? TLS_MODEL_INITIAL_EXEC : TLS_MODEL_LOCAL_EXEC));
where flag_pic can change any time some option is added or removed from
*.opt files.
But, it doesn't seem correct either, I think it should use
    set_decl_tls_model(decl, decl_default_tls_model(decl));
instead.  Or call decl_default_tls_model(decl) and adjust the result
depending on what it will return.

	Jakub

[Jakub Jelinek]

On Tue, Feb 06, 2024 at 01:50:14PM +0100, Jakub Jelinek wrote:
>  On Tue, Feb 06, 2024 at 12:38:31PM +0000, Richard W.M. Jones wrote:
>  > Not sure if it helps but it seems these source files implement the
>  > plugin:
>  > 
>  >
> https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/af...
>  >
> https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/af...
>  >
> https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/af...
>  > 
>  > and this header:
>  > 
>  >
> https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/af...
>  > 
>  > At a glance it seems like it uses a lot of APIs ...
>  
>  >From quick skimming, I've only noticed
>      set_decl_tls_model(
>          decl, (flag_pic ? TLS_MODEL_INITIAL_EXEC : TLS_MODEL_LOCAL_EXEC));
>  where flag_pic can change any time some option is added or removed from
>  *.opt files.
>  But, it doesn't seem correct either, I think it should use
>      set_decl_tls_model(decl, decl_default_tls_model(decl));
>  instead.  Or call decl_default_tls_model(decl) and adjust the result
>  depending on what it will return. 
BTW, if flag_pic ? TLS_MODEL_INITIAL_EXEC : TLS_MODEL_LOCAL_EXEC is
really what the plugins wants (e.g. that the TLS variable will be
defined in the same executable or same shared library and for shared
library doesn't mind making it non-dlopenable if other libraries deplete
the static TLS size), one hack might be to use e.g.
default_reloc_rw_mask () ? TLS_MODEL_INITIAL_EXEC : TLS_MODEL_LOCAL_EXEC
where default_reloc_rw_mask () is defined as return flag_pic ? 3 : 0;
for almost 17 years already, so could be a quick hack around trying to
remap flag_pic.

I'd really like to avoid exact gcc NVR dependency, at least if any gcc
updates would be refused because of that until somebody rebuilds the plugin
as well.  That was a reason why annobin has been changed to do the option
remapping...

	Jakub

[Florian Weimer]

* 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.

Thanks,
Florian

[Richard W.M. Jones]

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

[Kevin Kofler]

Richard W.M. Jones wrote:
>  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). 
See the discussion about my Plasma X11 packages. If you cannot avoid the 
hard version dependency (it looks like, in the GCC plugin case, it might be 
possible), this is the same situation.

        Kevin Kofler