From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZ4Zo-0002tj-Tf for qemu-devel@nongnu.org; Fri, 09 Dec 2011 12:49:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RZ4Zn-0003Pf-JP for qemu-devel@nongnu.org; Fri, 09 Dec 2011 12:49:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:64149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZ4Zn-0003Pb-4R for qemu-devel@nongnu.org; Fri, 09 Dec 2011 12:49:39 -0500 From: Paul Moore Date: Fri, 09 Dec 2011 12:49:26 -0500 Message-ID: <3829383.AcPyiEYLpa@sifl> In-Reply-To: <201112091732.20358.paul@codesourcery.com> References: <4EDFAF91.4070904@linux.vnet.ibm.com> <1776059.g3E9io5gG3@sifl> <201112091732.20358.paul@codesourcery.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Qemu-devel] [RFC] Device sandboxing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Ashley D Lai , Anthony Liguori , Stefan Hajnoczi , Corey Bryant , Michael Halcrow , qemu-devel@nongnu.org, Eric Paris , Radim =?utf-8?B?S3LEjW3DocWZ?= , Avi Kivity , Richa Marwaha , Amit Shah , Eduardo Terrell Ferrari Otubo , Lee Terrell , George Wilson On Friday, December 09, 2011 05:32:19 PM Paul Brook wrote: > > On Friday, December 09, 2011 04:17:50 PM Paul Brook wrote: > > > > A group of us are starting to work on sandboxing QEMU device > > > > emulation code. We're just getting started investigating > > > > various approaches, and want to engage the community to gather > > > > input. > > > > > > > > Following are the design points that we are currently > > > > considering: > > > > > > > > * Decompose QEMU into multiple processes: > > > > * This could be done such that QEMU devices execute in > > > > separate > > > > > > > > processes based on device type, e.g. all block > > > > devices in > > > > one > > > > process and all network devices in a second > > > > process. > > > > Another > > > > alternative is executing a separate process per > > > > device. > > > > > > I can't help wondering if nested virtualization would be a better > > > solution. i.e. have an outer VM that only implements a trusted > > > subset of devices. Inside that run a VM that provides the flakey > > > legacy device emulation you expect to be compromised. > > > > A few questions about this approach come to mind: > > > > 1. Does nested virtualization work across all the different hardware > > assisted virtualization platforms/CPUs? > > > > 2. What is the additional performance overhead for nested > > virtualization? > > Generalizations are okay, I'm just trying to get a basic understanding. > > > > 3. What, if any, management concerns are there with nested > > virtualization? > I don't have good answers to any of these questions. Then again I doubt > anyone has good answers for your proposed process splitting either. That's why we're working on a prototype. The questions weren't intended to be adversarial, just questions that I didn't know the answers to and thought you might ... > Last time I checked at least one of the Intel/AMD schemes had been > implemented, through I don't know if it's been merged, or had any serious > performance tuning. My main intent was to raise this as a potentially > viable alternative. Someone who actually cares about the answer can figure > out the details and cobble together some benchmarks :-) Well, if we see no answers and see no interest it probably isn't a viable alternative as no interest typically means no code. -- paul moore virtualization @ redhat