From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: A few KVM security questions Date: Mon, 07 Dec 2009 16:01:49 +0200 Message-ID: <4B1D0ACD.5020507@redhat.com> References: <4B1CFD93.7090307@invisiblethingslab.com> <4B1D0057.8030707@redhat.com> <4B1D094B.5000700@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Joanna Rutkowska Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19178 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935103AbZLGOBr (ORCPT ); Mon, 7 Dec 2009 09:01:47 -0500 In-Reply-To: <4B1D094B.5000700@invisiblethingslab.com> Sender: kvm-owner@vger.kernel.org List-ID: On 12/07/2009 03:55 PM, Joanna Rutkowska wrote: > >> It should be fairly easy to place qemu in a guest. You would leave a >> simple program on the host to communicate with kvm and pass any data >> written by the guest to qemu running in another guest, and feed any >> replies back to the guest. >> >> > But then you would need to have another qemu (on the host) to support > running this "qemu-VM", where we want to put the qemu, right? > Right, but to exploit this, you'd have to exploit the internal qemu, exploit the kernel, and exploit the external qemu. Well, if the exploit was in some central thing I guess there isn't much value in the nesting. You could alternatively use Xenner to run Xen guests for your qemu. That emulates a lot less. But AFAIK xenner is moving towards qemu as well. -- error compiling committee.c: too many arguments to function