From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35836 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q8Hnf-0001SJ-Eg for qemu-devel@nongnu.org; Fri, 08 Apr 2011 15:57:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q8Hne-0002Jq-2e for qemu-devel@nongnu.org; Fri, 08 Apr 2011 15:56:59 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:34051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q8Hnd-0002Jh-WB for qemu-devel@nongnu.org; Fri, 08 Apr 2011 15:56:58 -0400 Received: by vws17 with SMTP id 17so3425327vws.4 for ; Fri, 08 Apr 2011 12:56:57 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Fri, 8 Apr 2011 22:56:37 +0300 Message-ID: Subject: Re: [Qemu-devel] QEMU testing methodology & results Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Roberto Paleari Cc: qemu-devel@nongnu.org On Fri, Apr 8, 2011 at 10:18 AM, Roberto Paleari 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.