qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.


  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).