From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id A524C5A005E for ; Wed, 30 Nov 2022 02:33:07 +0100 (CET) Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4NMMCd42Nzz4xN1; Wed, 30 Nov 2022 12:33:01 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1669771981; bh=2VHhO8bmJswQ1gH/AeS6bfXqoBlh9uDC+O+Ivm0yMho=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=O0DGr6zntagRm9AXLQKHscA0EJdyRUmD1DtDtAQvNYWAtbPUjygJWXkKE3ZkjzGOm OmnXDv6v/tH9XC2Oa3k7uOyK0Q0t86yetuA59zB8gsvG3XlZSR7epo/6HW+5hV7afG xfL96WUK3Yvx55+5l+qV8YGsQgqbJNdQqwDCIJvw= Date: Wed, 30 Nov 2022 12:11:11 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH passt v2 0/7] Add fuzzing Message-ID: References: <20221117184938.2270462-1-rjones@redhat.com> <20221125102354.0540ad95@elisabeth> <20221125101103.GO7636@redhat.com> <20221129143442.4ae32a9b@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KEdMji8zbSSdy9pd" Content-Disposition: inline In-Reply-To: <20221129143442.4ae32a9b@elisabeth> Message-ID-Hash: ZLPGLNNJTF5E6H2Z7MX2ZJBH3OXAOY2D X-Message-ID-Hash: ZLPGLNNJTF5E6H2Z7MX2ZJBH3OXAOY2D X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "Richard W.M. Jones" , passt-dev@passt.top X-Mailman-Version: 3.3.3 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --KEdMji8zbSSdy9pd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 29, 2022 at 02:34:42PM +0100, Stefano Brivio wrote: > On Fri, 25 Nov 2022 10:11:03 +0000 > "Richard W.M. Jones" wrote: >=20 > > On Fri, Nov 25, 2022 at 10:23:54AM +0100, Stefano Brivio wrote: > > > and introducing frames with special values, as you hinted on IRC, for > > > example one-byte frames with commands such as "go ahead with socket > > > processing then come back to 'tap' frames", so that passt has a chance > > > to do some meaningful socket-side operations before getting back to > > > fuzz input. =20 > >=20 > > You can improve the chance that the fuzzer will find these frames by > > either including them in test cases (we need better test cases, which > > is separate issue), or by making the encoding such that they are easy > > to find. eg. if you had four possible values, encode them only in the > > bottom two bits and ignore the higher bits. Since these frames are > > only used for fuzzing you can change the meaning of them later, so > > exact encoding isn't an ABI issue. >=20 > Right, yes, I was thinking we could, under #ifdef FUZZING, accept > frames that are shorter than a 802.3 header (up to 13 bytes), and take > their length (in network order, but I guess AFL++ can easily get > familiar with it) as fuzzing flow commands. >=20 > About test cases, I'm not sure this should be included in regular test > runs, because there's no reasonable definition for a test duration. I'd > rather have a separate script which keeps running indefinitely, updating > sources as they become available. I agree we don't want to do fuzzing per se as part of the regular test. However, it would be nice to replay specific fuzz-generated scenarios where we've previously found bugs, to avoid regression. I'm not really sure what would be involved in that. > > > Patch 7/7 is very useful and appreciated anyway as it demystifies the > > > whole topic for me, and we can probably recycle most of the > > > documentation. I'm not sure yet how/if the wrapper still fits with the > > > stuff I'm looking into. =20 > >=20 > > It would definitely be better to have passt itself be able to > > read a file off disk. > >=20 > > For example when we fuzz nbdkit we do not used or need a wrapper, > > because nbdkit has an -s / --single option that reads from stdin and > > writes to stdout. This was originally added to inetd support. > >=20 > > We drive nbdkit from the fuzzer directly like this: > >=20 > > afl-fuzz -i fuzzing/testcase_dir -o fuzzing/sync_dir -M fuzz01 \ > > ./server/nbdkit -s -t 1 ./plugins/memory/.libs/nbdkit-memory-plug= in.so 1M > >=20 > > (https://gitlab.com/nbdkit/nbdkit/-/blob/ef035f7090d8bec2700ef1f941e371= d351d647ad/fuzzing/README#L35-36) >=20 > Ah, I didn't know, interesting. On the other hand, would it really make > sense to add support for that (which has probably no use other than > fuzzing) instead of a hack with __AFL_FUZZ_TESTCASE_BUF and mmap()? >=20 > According to AFL++ documentation that should speed things up > considerably: > https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/= README.persistent_mode.md#5-shared-memory-fuzzing >=20 --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --KEdMji8zbSSdy9pd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoULxWu4/Ws0dB+XtgypY4gEwYSIFAmOGrZkACgkQgypY4gEw YSLrhw//emp88a0SJGsyMsj+MC1SpFsmAVgxheRc3+qP0Xr1vM58Q9d/LgrJT9Cx gF+6vZq0M18vnlyUtEjpRM2EET9b1hrFnhrAOAHQlqp2nGmy+nHkVuTRx7bGcbcV KgJ9GXk4BEf8zag/oFhwQlh/z5/d0xBDsE+Y9TkM7bx7NRTMcHszQuvTfD7HFjDO u7HJ+lWWTrOFTlCyf3uObZ/DiT/YchPt79ZMY4KAkA2ISq9YqWi+kTmZFxuWI6sm rwhnRawIBLQ8jAxJNyzfORmXYTxzRmJEHw8S13eJyfe7IXFZDVyfO/aBtUobBPQo 9MUuxZ51AWkTHcRd8v80HP44LVxCStx95zYf1h2GxH8TZChJMZ4jcCsZmx14W9u/ nwS47GR4w68x7A1f5mg52ncdof2PZo4ipGd2LVmxe+m9wYm08sFy5VeYoGI5SbVS EcQc4ZLPlJdNDJF9P1whjoUOWKu6UFzSCLbgtMMiJU11dKR0cvkroXFKWvq66IgT S1J0EwXgLqKl3RGWqBsjirMfJ4kY2Akpkp7BI7nSB5agSN/I/jMdGxapzVRr6Vuf yy5gjucCaJng/EtIXQY2NwCzM+oWkLhOUUGPX6ywwqsXV36i+r+NmG3/gZJejrrc FrgZwS1pW3rjG82yELoE4hA65O9bUDSHtk8q1lRc5PvoJxwblcY= =T1IV -----END PGP SIGNATURE----- --KEdMji8zbSSdy9pd--