From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH 3/3] KVM: x86 emulator: fuzz tester Date: Thu, 25 Aug 2011 13:27:53 -0300 Message-ID: <20110825162753.GA6617@amt.cnet> References: <1314020469-30882-1-git-send-email-avi@redhat.com> <1314020469-30882-4-git-send-email-avi@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lmr@redhat.com, kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:17670 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752188Ab1HYQ2G (ORCPT ); Thu, 25 Aug 2011 12:28:06 -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 p7PGS65V012917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 25 Aug 2011 12:28:06 -0400 Content-Disposition: inline In-Reply-To: <1314020469-30882-4-git-send-email-avi@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. > > One way to run the test is via KVM itself: > > qemu -enable-kvm -smp 4 -serial stdio -kernel bzImage \ > -append 'console=ttyS0 test_emulator.iterations=1000000000' > > this requires that the test module be built into the kernel. > > Signed-off-by: Avi Kivity > --- > arch/x86/Kbuild | 1 + > arch/x86/kvm/Kconfig | 11 + > arch/x86/kvm/Makefile | 1 + > arch/x86/kvm/test-emulator.c | 533 ++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 546 insertions(+), 0 deletions(-) > create mode 100644 arch/x86/kvm/test-emulator.c > > + .fetch = test_fetch, > + .read_emulated = test_read, > + .write_emulated = test_write, > + .cmpxchg_emulated = test_cmpxchg, > + .invlpg = test_invlpg, > + .pio_in_emulated = test_pio_in, > + .pio_out_emulated = test_pio_out, > + .get_segment = test_get_segment, > + .set_segment = test_set_segment, > + .get_cached_segment_base = test_get_cached_segment_base, > + .get_gdt = test_get_desc_table, > + .get_idt = test_get_desc_table, > + .set_gdt = test_set_desc_table, > + .set_idt = test_set_desc_table, > + .get_cr = test_get_cr, > + .set_cr = test_set_cr, > + .cpl = test_cpl, > + .get_dr = test_get_dr, > + .set_dr = test_set_dr, > + .set_msr = test_set_msr, > + .get_msr = test_get_msr, > + .halt = test_halt, > + .wbinvd = test_wbinvd, > + .fix_hypercall = test_fix_hypercall, > + .get_fpu = test_get_fpu, > + .put_fpu = test_put_fpu, > + .intercept = test_intercept, > +}; > + > +static int modes[] = { > + X86EMUL_MODE_REAL, > + X86EMUL_MODE_VM86, > + X86EMUL_MODE_PROT16, > + X86EMUL_MODE_PROT32, > + X86EMUL_MODE_PROT64, > +}; > + > +static int test_emulator_one(struct test_context *test) > +{ > + struct x86_emulate_ctxt *ctxt = &test->ctxt; > + unsigned i; > + int r; > + > + test->failed = false; > + i = 0; > + if (random32() & 1) > + test->insn[i++] = 0x0f; > + for (; i < 15; ++i) > + test->insn[i++] = random32(); > + test->insn_base_valid = false; > + ctxt->ops = &test_ops; > + ctxt->eflags = randlong(); > + ctxt->eip = randlong(); > + ctxt->mode = modes[random32() % ARRAY_SIZE(modes)]; > + ctxt->guest_mode = random32() % 16 == 0; > + ctxt->perm_ok = random32() % 16 == 0; > + ctxt->only_vendor_specific_insn = random32() % 64 == 0; > + memset(&ctxt->twobyte, 0, > + (void *)&ctxt->regs - (void *)&ctxt->twobyte); > + 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. 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).