Re: [PATCH 3/3] KVM: x86 emulator: fuzz tester

[Marcelo Tosatti <mtosatti@redhat.com>]

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 <avi@redhat.com>
> ---
>  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).