afl-qemu: update to qemu 2.10.0, as specified by afl 2.52b #51398
Conversation
pkgs/tools/security/afl/qemu.nix
Outdated
| # patches extracted from afl source | ||
| ./qemu-patches/elfload.patch | ||
| ./qemu-patches/cpu-exec.patch | ||
| ./qemu-patches/syscall.patch |
There was a problem hiding this comment.
Can these patches be downloaded instead of living in the nixpkgs source tree?
There was a problem hiding this comment.
Unlikely - I've hand-modified at least one of them. See the README as to how/why this is necessary.
There was a problem hiding this comment.
Can you use fetchpatch for the unmodified ones?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
refresh patches & configure options directly from afl 2.52b to make installation as vanilla as possible
risicle
force-pushed
the
ris-afl-qemu-fix
branch
from
2131a52
to
5a09820
Compare
|
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 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. |
|
Any word on this? |
|
I made some cleanups but only check if they build. Mind having a look at it? |
|
Will do so... |
|
Works for me 👍 |
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
masterandrelease-18.09doesn'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 varQEMU_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
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)