Hi Mark, > Once you > have the bytes you can simply call Elf *elf_memory (char *__image, > size_t __size), There is no need to first write out the image to disk > and then use a file descriptor to read it back in.
I think I should have mentioned in the commit message that the fuzz target came from systemd where elfutils is hidden behind functions receiving filenames and file descriptors and I wanted to cover that code. If I had switched to elf_memory I couldn't have covered the code paths used by systemd. I agree that in other fuzz targets I'm planning to add elf_memory should be used instead but it would be great if it was possible to keep this kind of systemd-specific target. > One thing I struggle with is the initial seed (corpus). It needs to be > as small as possible, but also contain some valid ELF (core) files, so > that the fuzzer knows which valid paths there are to try out. How did > you construct the initial corpus? I normally try to create at least > four (little|big) endian and (32|64) bit minimal valid ELF files, but > that is not always easy. I think the name of that directory is a misnomer because it isn't a seed corpus. I should have probably called it "fuzz-dwfl-core-crashes" or "fuzz-dwfl-core-regressions" because I simply put files that have triggered various issues there. I think initially I just added a valid core file used in the systemd testsuite and let OSS-Fuzz deal with the rest. More generally, with OSS-Fuzz I kind of use brute force to get corpora covering as much code as possible with as few files as possible and with them it usually takes about 5-10 seconds to figure out whether new bugs are introduced or not. Eventually those corpora can be downloaded, unpacked and used in test scripts. elfutils hasn't been there long enough to get links to those corpora but for example one of systemd corpora can be downloaded from https://storage.googleapis.com/systemd-backup.clusterfuzz-external.appspot.com/corpus/libFuzzer/systemd_fuzz-varlink/public.zip > Finally I wonder if we cannot integrate the logic in build-fuzzers.sh > in the normal auto* build and create a "make fuzz" target that simply > uses CC=afl-gcc or CC=hfuzz-gcc and runs afl-fuzz or honggfuzz for a > couple of minutes if installed/detected by configure. I think it's a good idea but I'm not sure how to make that all compatible with OSS-Fuzz. I'll try to figure out how to do that. > The > build-fuzzers.sh script seems very specific to a google setup which > most people won't have locally and which seems somewhat tricky to > replicate on other CI builders. I tried to decouple it from OSS-Fuzz as much as I could so in its current form to build the fuzzer with LibFuzzer it should be enough to install clang and run the script.
