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

[Roberto Paleari <roberto@idea.sec.dico.unimi.it>]

On Fri, Apr 8, 2011 at 9:56 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> Very interesting!

Thank you!

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

Yes, KEmuFuzzer is more general and more effective than EmuFuzzer, as
it can be also used to test privileged instruction.

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

I agree: it would be really difficult to avoid red pills at all.
However, in EmuFuzzer and KEmuFuzzer we are interested only in
"instruction-level" red pills. I mean, we focused only on possibile
defects in the implementation of the instruction semantics, so we do
not take into account possibile red pills caused by clock skews,
device IDs, and so on.

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

I agree: the papers already disclose some details that could allow
"black hats" to re-implement the same approaches and eventualy find
emulation defects. However, we prefered to contact QEMU developers
before disclosing the details of the defects we found.

Thank you!
Roberto

-- 
Roberto Paleari
http://roberto.greyhats.it/
PGP Key Fingerprint: F94C 1933 F61C 3948 7CDD  2C61 38C7 6116 833D D6A0