From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZ4JI-0000Ot-8j for qemu-devel@nongnu.org; Fri, 09 Dec 2011 12:32:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RZ4JD-0000XU-V2 for qemu-devel@nongnu.org; Fri, 09 Dec 2011 12:32:36 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:50218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZ4JD-0000XP-QA for qemu-devel@nongnu.org; Fri, 09 Dec 2011 12:32:31 -0500 From: Paul Brook Date: Fri, 9 Dec 2011 17:32:19 +0000 References: <4EDFAF91.4070904@linux.vnet.ibm.com> <201112091617.50928.paul@codesourcery.com> <1776059.g3E9io5gG3@sifl> In-Reply-To: <1776059.g3E9io5gG3@sifl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112091732.20358.paul@codesourcery.com> Subject: Re: [Qemu-devel] [RFC] Device sandboxing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Moore Cc: Ashley D Lai , Anthony Liguori , Stefan Hajnoczi , Corey Bryant , Michael Halcrow , qemu-devel@nongnu.org, Eric Paris , Radim =?utf-8?q?Kr=C4=8Dm=C3=A1=C5=99?= , Avi Kivity , Richa Marwaha , Amit Shah , Eduardo Terrell Ferrari Otubo , Lee Terrell , George Wilson > 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. 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 :-) Paul