From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward501o.mail.yandex.net (forward501o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::611]) by sourceware.org (Postfix) with ESMTPS id 463063858D28 for ; Fri, 17 Dec 2021 12:23:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 463063858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ya.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ya.ru Received: from myt5-da0aad1c0099.qloud-c.yandex.net (myt5-da0aad1c0099.qloud-c.yandex.net [IPv6:2a02:6b8:c12:570c:0:640:da0a:ad1c]) by forward501o.mail.yandex.net (Yandex) with ESMTP id 8879145C4723; Fri, 17 Dec 2021 15:23:16 +0300 (MSK) Received: from myt5-ca5ec8faf378.qloud-c.yandex.net (myt5-ca5ec8faf378.qloud-c.yandex.net [2a02:6b8:c12:2514:0:640:ca5e:c8fa]) by myt5-da0aad1c0099.qloud-c.yandex.net (mxback/Yandex) with ESMTP id 8WoXeUrNQP-NGeutYSi; Fri, 17 Dec 2021 15:23:16 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1639743796; bh=X37jL/xcZKy8FPgsjbRvY77RbjlsbhOcOwdHmE9HE8Q=; h=Subject:Cc:From:To:Message-Id:In-Reply-To:References:Date; b=J3ccEcGL+nz+DrTLTGcvzTMFqphp5eTz0Kj/MtcVDP3hTpbmE49KIdYO+2v995Ucg YbQoVF9JW6MO0QXCYi0uill/7bTttduFYbtQ3/dSlW9Qy2kSzg3RLgFbsmJ5BuZiU1 6WeQfHPcPMGa/5dig5yLO1RTdMzjzO0eZnB+UqZE= Authentication-Results: myt5-da0aad1c0099.qloud-c.yandex.net; dkim=pass header.i=@ya.ru Received: by myt5-ca5ec8faf378.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 9F8f24RFjS-NFPWi2Xq; Fri, 17 Dec 2021 15:23:15 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) X-Yandex-Fwd: 2 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: [PATCH] tests: integrate fuzz-dwfl-core into elfutils From: Evgeny Vereshchagin In-Reply-To: Date: Fri, 17 Dec 2021 15:23:15 +0300 Cc: elfutils-devel@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <6141BF42-0685-4ED6-AEA1-E5B16C345273@ya.ru> References: <20211212151658.60269-1-evvers@ya.ru> To: Mark Wielaard X-Mailer: Apple Mail (2.3445.104.21) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_STORAGE_GOOGLE, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_SBL_A autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 12:23:21 -0000 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=3Dafl-gcc or CC=3Dhfuzz-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.=