Re: [libvirt] [GSOC] project libvirt fuzzing
On 03/21/2017 04:34 PM, Peter Krempa wrote:
On Tue, Mar 21, 2017 at 16:15:35 +0100, Michal Privoznik wrote:
> On 03/21/2017 04:39 AM, D L wrote:
>> On Thu, Mar 16, 2017 at 1:03 PM, Michal Privoznik <mprivozn(a)redhat.com>
>> wrote:
[...]
>> necessary. This might be one of the cases where programming is necessary for
>> this project.
>
> I don't think that we want to fuzz functions callde from
> qemuBuildCommandLine() separately. That indeed would be too overwhelming. I
> think we would be perfectly okay with fuzzing the qemuBuildCommandLine()
> itself (well, with help of XML parsing as described in my previous e-mails).
> So we might focus on generating XMLs for now (e.g. write a grammar that does
> that? dunno - don't have much experience with fuzzers). The whole idea that
Ideally it should take the grammar we have for our XMLs so that we don't
have to update it manually all the time.
While this would certainly be interesting thing to do I'm afraid of two
things here:
1) state explosion - our XML schema is so complicated that trying to
generate each state it could be in depending on grammar would lead to
"uncountable" many states. Plus calling 2) + 3) over them would take
ages to finish. But we can aim on a very basic subset for now and
probably expand that later?
2) Reversing the process from RNG to XML generation: how would that even
work? I mean, how do you parse RNG schema and reason about it? I know
it's an XML document just like any other, but what I am interested in is
how to catch the meaning of rules written in the schema. For instance:
<element name="blah">
<zeroOrMore>
<element name="subBlah">
<text/>
</element>
</zeroOrMore>
</element>
We all know what this simple grammar can generate. But if I were to
write a program that parses the rules and generates XML documents
according to them, I'd probably end up hiding under the desk.
> I have in my mind is as follows:
>
> 1) let fuzzer genereate a XML document
> 2) def = virDomainDefParse*(document);
> 3) qemuBuildCommandLine(def);
> 4) if SIGSEGV store XML somewhere for future inspection
including backtrace
Ah, sure.
> 5) goto 1)
>
Michal