[libvirt] [GSOC] project libvirt fuzzing

D L srwx4096 at gmail.com
Tue Mar 21 18:04:49 UTC 2017


On Tue, Mar 21, 2017 at 11:15 AM, Michal Privoznik <mprivozn at redhat.com>
wrote:

> On 03/21/2017 04:39 AM, D L wrote:
>
>> On Thu, Mar 16, 2017 at 1:03 PM, Michal Privoznik <mprivozn at redhat.com>
>> wrote:
>>
>
> Hi Michal,
>>>
>>
> Hey,
>
>
>> I have been digesting your comments. Then I switched concentration from
>> general
>>  instrumentation and fuzzing to qemuBuildCommandLine(). I have been having
>> difficulties of resolving the dependencies/shared objects in order to fuzz
>> a particular
>> function. Then I came to a conclusion, I would imagine, but have not
>> started yet,
>> to target specific functions, some helper functions need to be in place to
>> be
>> responsible of the callbacks, and it seems hand-crafted instrumentation is
>> also
>> 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 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
> 5) goto 1)
>
> For points 2) and 3) we might need to create a binary, but that should be
> fairly easy to do. Does this sound reasonable to you?
>
> That's great. I really appreciate the clarity. Yes, I also think we need
to generate binaries. The work flow sounds reasonable for me now.

>
>> Given the slow progress, or maybe I started later than an ideal situation,
>> I am a
>> bit worried if I could finish the requirement before the submission
>> deadline, not
>> to mention other libvirt community-specific requirement mentioned on the
>> website.
>>
>
> Well, the requirements for submitting are not have all the coding ready
> :-).  You can check the requirements here:
>
> http://wiki.libvirt.org/page/Google_Summer_of_Code_FAQ
>
> Then, for the student application you should describe in the form how you
> want to achieve the goal, design some time line and so on. Don't worry, you
> can edit it until the deadline.

Thanks a lot for letting me know again about this.


>
>
>
>> So to make sure I am on the right track, what are the concrete goals to
>> achieve,
>> specific requirement to meet, or procedures for me to follow in order to
>> submit
>> the application by the deadline?
>>
>>
> Well, you've successfully subscribed to the list and I assume you've
> cloned and compiled libvirt. So what you need to do is to prove it - send a
> patch that fixes something in libvirt. There is a link in the FAQ to a list
> of bite sized tasks. Or I can think of something easy if you want.>
> > Michal
>
>
> Yes, I compiled, installed, and used the binaries successfully.
Could you confirm the location of bug list is the following, please?

https://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Virtualization%20Tools
https://bugzilla.redhat.com/enter_bug.cgi?product=Virtualization%20Tools&component=libvirt
"This list is too long for Red Hat Bugzilla's little mind"

I will take a look at several of the latest ones see if I can solve one of
them; I will let you know otherwise.

Thanks a lot,

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170321/ba100166/attachment-0001.htm>


More information about the libvir-list mailing list