From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MC0jD-0005fi-Jb for qemu-devel@nongnu.org; Wed, 03 Jun 2009 20:22:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MC0j9-0005dY-8l for qemu-devel@nongnu.org; Wed, 03 Jun 2009 20:22:43 -0400 Received: from [199.232.76.173] (port=41202 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MC0j9-0005dV-5B for qemu-devel@nongnu.org; Wed, 03 Jun 2009 20:22:39 -0400 Received: from mx20.gnu.org ([199.232.41.8]:39241) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MC0j8-0000Td-Vl for qemu-devel@nongnu.org; Wed, 03 Jun 2009 20:22:39 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MC0j6-0002CT-KW for qemu-devel@nongnu.org; Wed, 03 Jun 2009 20:22:37 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: Re: Killing KQEMU Date: Thu, 4 Jun 2009 01:22:33 +0100 References: <20090602035217.GA16574@foursquare.net> <20090602204714.GA16314@miranda.arrow> <20090603212142.GA16171@foursquare.net> In-Reply-To: <20090603212142.GA16171@foursquare.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906040122.33938.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Chris Frey > > More like "impossible because it *should* never happen". kqemu is not > > known to be secure. > > Did you mean "kqemu is known to not be secure" or is this just FUD? AFAIK noone has produced a real-work exploit, but see below. > The KQEMU technical documentation on the QEMU website specifically > stresses that no VM code is run at kernel level, so someone was thinking > about security when it was written. Absolutely not. The fact that all guest code is run in ring3 is in no way in indication that the end result is secure. I know from experience[1] that there are many ways that such a VM an be compromised. Pretty much every mainstream x86 operating system in the last 15 years runs application code in ring3, but that doesn't mean they're even vaguely secure. My understanding is that kqemu is known to not work correctly under certain circumstances. It's possible that this never occurs when common guest operating systems are operating normally. However if a guest is compromised it is likely that it will be able to either compromise or DoS(crash) the host machine. Empirical evidence suggests that in practice this happens even without malicious intent. Paul [1] I wrote a prototype kqemu equivalent, so have been intimately familiar with many of the things that can go wrong.