On Fri, Apr 8, 2011 at 10:18 AM, Roberto Paleari <robe...@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 emufuz...@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.
