From: Darren Kenny <darren.kenny@oracle.com>
To: Alexander Bulekov <alxndr@bu.edu>
Cc: Laurent Vivier <lvivier@redhat.com>,
Thomas Huth <thuth@redhat.com>,
qemu-devel@nongnu.org, f4bug@amsat.org, bsd@redhat.com,
stefanha@redhat.com, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v2 02/15] fuzz: Add general virtual-device fuzzer
Date: Mon, 07 Sep 2020 16:55:58 +0100 [thread overview]
Message-ID: <m2sgbt4m41.fsf@oracle.com> (raw)
In-Reply-To: <20200907153932.pyzeiegsa3plzm37@mozz.bu.edu>
On Monday, 2020-09-07 at 11:39:32 -04, Alexander Bulekov wrote:
> On 200902 1103, Darren Kenny wrote:
...
>> > +
>> > + while (ind >= 0 && fuzzable_memoryregions->len) {
>> > + *result = (address_range){0, 0};
>> > + mr = g_ptr_array_index(fuzzable_memoryregions, i);
>> > + if (mr->enabled) {
>> > + abs_addr = mr->addr;
>> > + for (root = mr; root->container; ) {
>> > + root = root->container;
>> > + abs_addr += root->addr;
>> > + }
>> > + /*
>> > + * Only consider the region if it is rooted at the io_space we want
>> > + */
>> > + if (root == io_space) {
>> > + hwaddr xlat, len;
>> > + if(address_space_translate(as, abs_addr, &xlat, &len, true, MEMTXATTRS_UNSPECIFIED) == mr){
>> > + ind--;
>>
>> I'm wondering what is the purpose of ind, we never really do anything
>> with it except possibly decrement it here and test in the while
>> condition.
>>
>> With candidate_regions also only being incremented here, we could just
>> as easily compare that against index.
>>
>
> Yes it is not clear. The overall idea here is:
> * fuzzable_memoryregions contains regions that belong both to the
> Memory/MMIO AddressSpace and the PIO AddressSpace.
> * Thus fuzzable_mr can look like [PIO_1, MMIO_1, MMIO_2, PIO_2, PIO_3]
> * If index == 4 and we want an MMIO region, we need to use that as an
> index into the sub-array of only MMIO-Type regions
>
> I think instead, I should either
> 1. Have separate arrays for PIO/MMIO MRs. This will simplify this
> function, but I'm also not sure whether it is always possible to
> identify whether the mr is pio/mmio (e.g. when a PCI BAR has not yet
> been mapped)
> 2. Have a single read/write operation instead of in/out and read/write.
> Then, instead of differentiating between MMIO and PIO here, we could
> do that in the OP.
> 3. Instead of keeping track of MemoryRegions here, try instead to walk
> the corresponding "flatview" and match the memory-region pointers.
>
> I'll try out (3) first. hopefully that will clear this up and make
> everything more legible.
OK, thanks.
...
>> > +/*
>> > + * Here, we interpret random bytes from the fuzzer, as a sequence of commands.
>> > + * Our commands are variable-width, so we use a separator, SEPARATOR, to specify
>> > + * the boundaries between commands. This is just a random 32-bit value, which
>> > + * is easily identified by libfuzzer+AddressSanitizer, as long as we use
>> > + * memmem. It can also be included in the fuzzer's dictionary. More details
>> > + * here:
>> > + * https://github.com/google/fuzzing/blob/master/docs/split-inputs.md
>> > + *
>> > + * As a result, the stream of bytes is converted into a sequence of commands.
>> > + * In a simplified example where SEPARATOR is 0xFF:
>> > + * 00 01 02 FF 03 04 05 06 FF 01 FF ...
>> > + * becomes this sequence of commands:
>> > + * 00 01 02 -> op00 (0102) -> in (0102, 2)
>> > + * 03 04 05 06 -> op03 (040506) -> write (040506, 3)
>> > + * 01 -> op01 (-,0) -> out (-,0)
>> > + * ...
>> > + *
>> > + * Note here that it is the job of the individual opcode functions to check
>> > + * that enough data was provided. I.e. in the last command out (,0), out needs
>> > + * to check that there is not enough data provided to select an address/value
>> > + * for the operation.
>> > + */
>>
>> Out if curiosity, do any of our corpus actually make use of the FUZZ string, or are we
>> just falling back to always using the full size of the provided input?
>>
>
> Do you mean if there is some case where "FUZZ" needs to be used as a
> real value, rather than a magical separator?
>
> Or are asking whether the fuzzer actually generates inputs with the
> "FUZZ" separator?
> With ASan enabled, libfuzzer immediately figures out that "FUZZ" is an
> interesting string (because it instruments memmem) and starts inserting
> it all over the place. Without --enable-sanitizers, I add it to a fuzzer
> dictionary for the same effect (see bullet-point 1 in PATCH v2 00/15).
Should have responded to this, saw that you also used FUZZ later in the
patchset when I finally got there :)
Thanks,
Darren.
next prev parent reply other threads:[~2020-09-07 15:56 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 6:10 [PATCH v2 00/15] Add a General Virtual Device Fuzzer Alexander Bulekov
2020-08-19 6:10 ` [PATCH v2 01/15] fuzz: Change the way we write qtest log to stderr Alexander Bulekov
2020-08-19 6:10 ` [PATCH v2 02/15] fuzz: Add general virtual-device fuzzer Alexander Bulekov
2020-09-02 10:03 ` Darren Kenny
2020-09-07 15:39 ` Alexander Bulekov
2020-09-07 15:55 ` Darren Kenny [this message]
2020-08-19 6:10 ` [PATCH v2 03/15] fuzz: Add PCI features to the general fuzzer Alexander Bulekov
2020-09-02 11:01 ` Darren Kenny
2020-08-19 6:10 ` [PATCH v2 04/15] fuzz: Add DMA support to the generic-fuzzer Alexander Bulekov
2020-09-03 8:43 ` Darren Kenny
2020-09-07 15:45 ` Alexander Bulekov
2020-08-19 6:11 ` [PATCH v2 05/15] fuzz: Declare DMA Read callback function Alexander Bulekov
2020-09-03 8:44 ` Darren Kenny
2020-08-19 6:11 ` [PATCH v2 06/15] fuzz: Add fuzzer callbacks to DMA-read functions Alexander Bulekov
2020-09-03 8:46 ` Darren Kenny
2020-08-19 6:11 ` [PATCH v2 07/15] fuzz: Add support for custom crossover functions Alexander Bulekov
2020-09-03 8:50 ` Darren Kenny
2020-08-19 6:11 ` [PATCH v2 08/15] fuzz: add a DISABLE_PCI op to general-fuzzer Alexander Bulekov
2020-09-03 8:49 ` Darren Kenny
2020-08-19 6:11 ` [PATCH v2 09/15] fuzz: add a crossover function to generic-fuzzer Alexander Bulekov
2020-09-03 9:04 ` Darren Kenny
2020-08-19 6:11 ` [PATCH v2 10/15] scripts/oss-fuzz: Add wrapper program for generic fuzzer Alexander Bulekov
2020-09-03 9:07 ` Darren Kenny
2020-09-03 9:10 ` Darren Kenny
2020-08-19 6:11 ` [PATCH v2 11/15] scripts/oss-fuzz: Add general-fuzzer build script Alexander Bulekov
2020-09-03 9:15 ` Darren Kenny
2020-08-19 6:11 ` [PATCH v2 12/15] scripts/oss-fuzz: Add general-fuzzer configs for oss-fuzz Alexander Bulekov
2020-09-03 9:16 ` Darren Kenny
2020-08-19 6:11 ` [PATCH v2 13/15] scripts/oss-fuzz: build the general-fuzzer configs Alexander Bulekov
2020-09-03 9:17 ` Darren Kenny
2020-09-07 15:49 ` Alexander Bulekov
2020-08-19 6:11 ` [PATCH v2 14/15] scripts/oss-fuzz: Add script to reorder a general-fuzzer trace Alexander Bulekov
2020-09-03 9:20 ` Darren Kenny
2020-08-19 6:11 ` [PATCH v2 15/15] scripts/oss-fuzz: Add crash trace minimization script Alexander Bulekov
2020-09-03 9:28 ` Darren Kenny
2020-08-19 6:32 ` [PATCH v2 00/15] Add a General Virtual Device Fuzzer no-reply
2020-08-19 16:23 ` Alexander Bulekov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2sgbt4m41.fsf@oracle.com \
--to=darren.kenny@oracle.com \
--cc=alxndr@bu.edu \
--cc=bsd@redhat.com \
--cc=f4bug@amsat.org \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).