qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Disk image fuzz testing (OPW)


From: M.Kustova
Subject: Re: [Qemu-devel] Disk image fuzz testing (OPW)
Date: Mon, 26 May 2014 13:53:57 +0400

Hello Kevin,
Thanks a lot for your feedback.

Your first guess is absolutely correct. For now, 'action' can be
freely interpret as an image block will be corrupted. It's possible,
that in the future this term will be extended to a set of fuzzing
rules necessary to corrupt some image block, e.g. not only create a
wrong snapshot  table entry but support it with a valid snapshot. But
for now, 'action' is just a image block, like a header field or L1
table.

About fuzzer effectiveness. 'qemu-img' was set as the fuzzer target,
so its commands under interest are any that modify or/and read an
image. As first step, a tested command will be selected randomly or
specified by user. After investigation of code coverage on the final
stage of the project additional constrains will be added to the
algorithm selecting blocks to be fuzzed.

Thanks again for useful questions.

BR, M.

On Mon, May 26, 2014 at 12:43 PM, Kevin Wolf <address@hidden> wrote:
> Hi Maria,
>
> Am 26.05.2014 um 07:07 hat M.Kustova geschrieben:
>> My name is Maria and  I'm a participant of the Outreach Program for Women.
>> My project is fuzz testing of support of qcow2 image format.
>>
>> The project git:
>> https://github.com/maxalab/qemu_fuzzer.git
>>
>> It's pubic, so welcome, make yourself at home.
>
> Thanks for sharing this. I read your requirements file and have a
> question or two.
>
> The first is about what "actions" are. You define it as "structure
> elements retrieved from an image format" or "element of an image
> structure", which unfortunately doesn't make things much clearer to me.
> My guess is that you mean a data structure (like header, L1 table,
> refcount block, etc.) and this is the structure that is going to be
> modified during the fuzzing? Is this right?
>
> The other thing is that you seem to concentrate on generating test image
> (and probably rightly so), but there's also the part that you need to
> use that image for something, i.e. using the right actions with qemu to
> actually test it against that image in a meaningful way (for example,
> corrupting a snapshot's L1 table isn't interesting as long as this
> snapshot isn't touched). What are your plans for determining what test
> to run against the generated test images?
>
> Also, if you don't mind, I'd like to be CCed on your further emails
> about this project.
>
> Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]