afl-qemu: update to qemu 2.10.0, as specified by afl 2.52b

[risicle]

refresh patches & configure options directly from afl 2.52b to make
installation as vanilla as possible

Motivation for this change

afl's qemu mode as packaged in master and release-18.09 doesn't work (correct me if it's somehow working for you!), because instead of using the specified 2.10.0, it's been left at 2.3.0. This doesn't work because afl 2.52b passes an env var QEMU_LOG=nochain, which qemu 2.3.0 doesn't understand, failing with an error message.

The patches themselves had also been only minimally updated from what I can see, just enough to get them to compile. Here I've pulled the patches (and afl-types.h, afl-config.h) fresh from the afl 2.52b sources, but also pulled in a cherrypicked fix from qemu git to build against glibc 2.27.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Assured whether relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

[Mic92]

Can these patches be downloaded instead of living in the nixpkgs source tree?

[risicle]

Unlikely - I've hand-modified at least one of them. See the README as to how/why this is necessary.

[Mic92]

Can you use fetchpatch for the unmodified ones?

[risicle]

It's a bit odder than that actually - the patches actually come from the afl source tree itself, so really ideally there would be a neat way to fish them out of there...? Question is how to do it without introducing some kind of weird recursive dependency.

[Mic92]

Either you write a postPatch hook that calls patch or add something like something like: ${src}/qemu-patches/patch-name.patch to the patches list. Both should not have any problems with recursion.

[risicle]

It's not the qemu source the patches live in, but the afl source. This qemu is a dependency of afl, and to ensure the correct pairing of versions, I'll have to take that afl package (or at least its src file) as an argument to this function to be able to access it, hence my worry about recursion. It should be possible but will require some jiggery pokery.

[Mic92]

Since you are not depending on the build output but the source, this should not be a problem either. Using "${avl.src}/qemu-patches/patch-name.patch" should work too.

[risicle]

Ahok I'll try that

[risicle]

Ok this appears to do the right thing - not convinced it actually ends up with a clearer result and it requires the odd fixed-point-y thing in afl's default.nix, but whatever.

At some point I should probably also look at enabling it for more platforms - I think its x86 restriction is just there out of conservativeness.

[risicle]

Any word on this?

[Mic92]

I made some cleanups but only check if they build. Mind having a look at it?

[risicle]

Will do so...

[risicle]

Works for me 👍