Re: [Qemu-devel] QEMU testing methodology & results

[Blue Swirl <blauwirbel@gmail.com>]

On Fri, Apr 8, 2011 at 10:18 AM, Roberto Paleari
<roberto@security.dico.unimi.it> wrote:
> Dear QEMU developers,
>
> we are a group of researchers working at the University of Milan,
> Italy. During the last year we focused on automatic techniques to find
> defects inside CPU emulators and virtualizers. Our work has been
> published in different conference papers [1][2][3], and the testing
> methodologies we developed allowed us to find defects in several
> emulators and virtualizers, including QEMU.

Very interesting!

The test case generation is a bit like crashme program, but more
intelligent. It would be nice to integrate something like this to QEMU
as a test suite instead of manually written assembly programs.

KEmuFuzzer seems to be more general. The approach of the patch is a
bit intrusive. But there are similarities with it and GDB interface,
tracepoints and other instrumentation needs, so it may be possible to
work out a common solution.

I don't think it is possible to avoid red pills. Even with the fastest
hardware assisted emulator, it may be possible to make a program to
detect systematic distortions in the clock speed. Lack of cache
emulation may be easy to detect. The devices that QEMU provides are so
old that a machine with those devices can be considered to be QEMU by
the red pill. And so on.

> In these days we were asked to publicly release our experimental
> results. As these results also include several defects in QEMU, we
> believed it was better to contact you before releasing this material
> to the public.
>
> For this reason, we ask to whom it may concern to contact us privately
> at emufuzzer@security.dico.unimi.it to discuss about the disclosure of
> these results.

I'd vote for full disclosure and open discussion on this list, but I
suppose the distro people may have business interests to protect.
Though the papers may already give the black hats enough ideas how to
find the defects.