KVM guest-kernel panics double fault

["Stephan Bärwolf" <stephan.baerwolf@tu-ilmenau.de>]

[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]

Hello guys,

I am sorry to disturb you this short before New Year, but I think this
shouldn't wait until next year.

After experiencing crashes in virtual maschines and considering kernel /
qemu / kvm / cpu -bugs, I discovered the following (see patch) issue.
Because unpriviledged users can crash VMs, I think it is a serious one
and needs short-term attention.

The patch I wrote is against 3.2-rc7 but I always tested with linux 3.1.6.
Hopfully it solve the problems to your satisfaction.

regards and a happy new year,
    Stephan Bärwolf




Subject: [PATCH] KVM: fix missing "illegal instruction"-trap in guests
within non-64bit protected modes

On hosts without this patch, 32bit guests will crash for
example by simply executing following nasm-demo-application:

        [bits 32]
        global _start
        SECTION .text
        _start: syscall

(I am not sure if this can be exploited in more worse ways,
like breaking out of VMs in more complex szenarios?
But I tested it with win32 and linux - both always crashed)

        Disassembly of section .text:

        00000000 <_start>:
           0:   0f 05                   syscall

The reason seems a missing "invalid opcode"-trap (int6) for the
syscall opcode "0f05", which is not available on 32bit cpus.
Intel's "Intel 64 and IA-32 Architecture Software Developers
Manual" (http://www.intel.com/content/dam/doc/manual/
64-ia-32-architectures-software-developer-manual-325462.pdf)
documents on page 1804 (4-586) "syscall" is only available
in 64bit longmode. So "syscall" must trap in real- and
virtual 8086 -mode, as also in all non-64bit protected-modes.

The last ones (16 & 32bit protected mode) are not beeing checked
by kvm and so causing a missing trap as an double-fault-panic
on 32bit guests.

Also an initially not observed problem can be explained
with this bug:
On 64bit guests (x86_64) 32bit compat-programs are able to
syscall their kernel via "0f05" correctly, althought native
(not virtualized) systems would also trap!

This patch solves the described problem by extending the
checking of cpu's operational mode.

Screenshots of a i686 testing VM  before and after applying
this patch are available under:

http://matrixstorm.com/software/linux/kvm/20111229/before.jpg
http://matrixstorm.com/software/linux/kvm/20111229/after.jpg



[-- Attachment #2: 0001-KVM-fix-missing-illegal-instruction-trap-in-guests-w.patch --]
[-- Type: text/x-patch, Size: 2713 bytes --]

>From 4de09b4bdba4927b8e248daa1bbfacaf3752fb6e Mon Sep 17 00:00:00 2001
From: Stephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
Date: Thu, 29 Dec 2011 00:50:46 +0000
Subject: [PATCH] KVM: fix missing "illegal instruction"-trap in guests within non-64bit protected modes

On hosts without this patch, 32bit guests will crash for
example by simply executing following nasm-demo-application:

	[bits 32]
	global _start
	SECTION .text
	_start: syscall

(I am not sure if this can be exploited in more worse ways,
like breaking out of VMs in more complex szenarios?
But I tested it with win32 and linux - both always crashed)

	Disassembly of section .text:

	00000000 <_start>:
	   0:   0f 05                   syscall

The reason seems a missing "invalid opcode"-trap (int6) for the
syscall opcode "0f05", which is not available on 32bit cpus.
Intel's "Intel 64 and IA-32 Architecture Software Developers
Manual" (http://www.intel.com/content/dam/doc/manual/
64-ia-32-architectures-software-developer-manual-325462.pdf)
documents on page 1804 (4-586) "syscall" is only available
in 64bit longmode. So "syscall" must trap in real- and
virtual 8086 -mode, as also in all non-64bit protected-modes.

The last ones (16 & 32bit protected mode) are not beeing checked
by kvm and so causing a missing trap as an double-fault-panic
on 32bit guests.

Also an initially not observed problem can be explained
with this bug:
On 64bit guests (x86_64) 32bit compat-programs are able to
syscall their kernel via "0f05" correctly, althought native
(not virtualized) systems would also trap!

This patch solves the described problem by extending the
checking of cpu's operational mode.

Screenshots of a i686 testing VM  before and after applying
this patch are available under:

http://matrixstorm.com/software/linux/kvm/20111229/before.jpg
http://matrixstorm.com/software/linux/kvm/20111229/after.jpg

Signed-off-by: Stephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
---
 arch/x86/kvm/emulate.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index f1e3be1..60f6ffc 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -1886,7 +1886,15 @@ static int em_syscall(struct x86_emulate_ctxt *ctxt)
 	u64 efer = 0;
 
 	/* syscall is not available in real mode */
+	/* 
+	   "0f05" is also not available in
+	   all non-64-bit protected modes (16&
+	   32bit) or virtual 8086 mode		 
+	   Only 64bit longmode supports this opcode
+	*/
 	if (ctxt->mode == X86EMUL_MODE_REAL ||
+	    ctxt->mode == X86EMUL_MODE_PROT16 ||
+	    ctxt->mode == X86EMUL_MODE_PROT32 ||
 	    ctxt->mode == X86EMUL_MODE_VM86)
 		return emulate_ud(ctxt);
 
-- 
1.7.3.4