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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.