AFLplusplus: QEMU build breaks on new glibc

When using ubuntu 19.10 and AFL++ commit c124576a4dc00e31ad5cad118098f46eaa29cd17 everything worked perfectly fine before, but I think with the new glibc in ubuntu 19.10 it fails (see link below why I think that). I tried upgrading my Docker image to the new a67d86c6e2ca58db81f2ddf6d0a4c837be88271d commit (so I don’t think it is the new AFL++ but a glibc/QEMU problem):

$ apt-get update && apt-get -y install build-essential clang git python2.7-dev python2.7 && git clone /afl && cd /afl/ && git reset --hard a67d86c6e2ca58db81f2ddf6d0a4c837be88271d && make
$ cd /afl/libdislocator/ && make
$ cd /afl/llvm_mode && ln -s /usr/bin/llvm-config-? /usr/bin/llvm-config && make
$ cd /afl/ && make install
$ unset AFL_CC AFL_CXX AFL_AS && apt-get update && apt-get -y install libtool-bin wget bison libglib2.0-dev libpixman-1-dev python && cd /afl/qemu_mode && ./ && cd /afl/ && make install
  CC      x86_64-linux-user/accel/tcg/user-exec-stub.o
  CC      x86_64-linux-user/linux-user/main.o
  CC      x86_64-linux-user/linux-user/syscall.o
/afl/qemu_mode/qemu-3.1.0/linux-user/syscall.c:256:16: error: static declaration of 'gettid' follows non-static declaration
  256 | _syscall0(int, gettid)
      |                ^~~~~~
/afl/qemu_mode/qemu-3.1.0/linux-user/syscall.c:187:13: note: in definition of macro '_syscall0'
  187 | static type name (void)   \
      |             ^~~~
In file included from /usr/include/unistd.h:1170,
                 from /afl/qemu_mode/qemu-3.1.0/include/qemu/osdep.h:90,
                 from /afl/qemu_mode/qemu-3.1.0/linux-user/syscall.c:20:
/usr/include/x86_64-linux-gnu/bits/unistd_ext.h:34:16: note: previous declaration of 'gettid' was here
   34 | extern __pid_t gettid (void) __THROW;
      |                ^~~~~~
make[1]: *** [/afl/qemu_mode/qemu-3.1.0/rules.mak:69: linux-user/syscall.o] Error 1
make[1]: *** Waiting for unfinished jobs....
  LINK    ivshmem-server
  LINK    qemu-nbd
  LINK    qemu-img
make: *** [Makefile:483: subdir-x86_64-linux-user] Error 2

This seems to be this one:

If I understand it correctly this is more of a QEMU problem than an AFL++ problem, however, AFL++ still uses QEMU 3.1.0 instead of 3.1.1. So squeezing the following in:

sed -i "s/3.1.0/3.1.1/g" && sed -i "s/0318f2b5a36eafbf17bca0f914567dfa5e8a3cd6ff83bb46fe49a0079cd71ddd3ec4267c6c62a03f9e26e05cc80e6d4b/28ff22ec4b8c957309460aa55d0b3188e971be1ea7dfebfb2ecc7903cd20cfebc2a7c97eedfcc7595f708357f1623f8b/g"

It didn’t compile either 😦 So either QEMU support will be broken in newer glibc or we patch AFL++ or QEMU 4 support is ready soon. Unfortunately I can also not use an older version of 9.10, because in Docker images the version specification “9.10” is as granular as it gets.

Patching AFL++ shouldn’t be too hard, as there is already a syscall.diff patch…

Off-topic: I’m currently writing a Docker image for AFL++. I think AFL++ would really profit from a stable build environment, where tests could be run as well to make sure AFL++ still works correctly. With Docker multi-stage images I was able to build different images, with various features and different compile times if the Docker image would need updating. It was also only one command (rebuild the docker) to find the above issue. Moreover, I think it would really benefit the community, as installing AFL++, libdislocator, llvm_mode, recidivm, QEMU mode, afl-dyninst is probably already a problem for beginners. Having the same build environment would be the first step to simplify performance comparisons (together with -E -V options). With the Docker image it would as well be very easy to do some sort of continuous integration and building the newest release overnight and run additional tests… I’ll let you know some more about the Docker soon

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 15 (15 by maintainers)

Commits related to this issue

Most upvoted comments

Ok, I’m backporting the patch to QEMU 3.1.1, wait some minutes (I need you as tester cause I don’t have an Ubuntu 19.10 VM ready).

[+] Build process successful! in a second I’ll let you know if it also runs correctly (finds paths)… EDIT: rather some more hours, the same docker stage builds dyninst and afl-dyninst from scratch. But I’m pretty sure the patch is fine.