From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 3/3] KVM: x86 emulator: fuzz tester Date: Thu, 25 Aug 2011 22:04:52 +0300 Message-ID: <4E569CD4.6010101@redhat.com> References: <1314020469-30882-1-git-send-email-avi@redhat.com> <1314020469-30882-4-git-send-email-avi@redhat.com> <20110825162753.GA6617@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lmr@redhat.com, kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:48120 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753805Ab1HYTEz (ORCPT ); Thu, 25 Aug 2011 15:04:55 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7PJ4tki000747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 25 Aug 2011 15:04:55 -0400 In-Reply-To: <20110825162753.GA6617@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 08/25/2011 07:27 PM, Marcelo Tosatti wrote: > On Mon, Aug 22, 2011 at 04:41:09PM +0300, Avi Kivity wrote: > > The x86 emulator is directly exposed to guest code; therefore it is part > > of the directly exposed attack surface. To reduce the risk of > > vulnerabilities, this patch adds a fuzz test that runs random instructions > > through the emulator. A vulnerability will usually result in an oops. > > > > + for (i = 0; i< NR_VCPU_REGS; ++i) > > + ctxt->regs[i] = randlong(); > > + r = x86_decode_insn(ctxt, NULL, 0); > > It could rerun N times instructions that have been decoded successfully. > This would increase the chance of testing the code path for that (class > of) instruction. Good idea. I'll keep N small (20?) so that we fuzz the decoder as well. > Also fuzzing from an actual guest is useful to test the real backend > functions. What problem did you encounter? The new testsuite scheme > seems a good fit for that (with the exception of being locked to 32-bit > mode). Mostly that I forgot it exists. Other issues are that it's harder to force random values through it - though I could allocate a couple GB and fill it with random values. We also lose the ability to test inputs to callbacks (not that I do much of that here). I'll try it out. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.