qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: Paul Moore <pmoore@redhat.com>
Cc: "Ashley D Lai" <adlai@us.ibm.com>,
	"Anthony Liguori" <aliguori@us.ibm.com>,
	"Stefan Hajnoczi" <stefanha@gmail.com>,
	"Corey Bryant" <coreyb@linux.vnet.ibm.com>,
	"Michael Halcrow" <mhalcrow@google.com>,
	qemu-devel@nongnu.org, "Eric Paris" <eparis@redhat.com>,
	"Radim Krčmář" <radimkrcmar@hpx.cz>,
	"Avi Kivity" <avi@redhat.com>,
	"Richa Marwaha" <rmarwah@us.ibm.com>,
	"Amit Shah" <amit.shah@redhat.com>,
	"Eduardo Terrell Ferrari Otubo" <eotubo@br.ibm.com>,
	"Lee Terrell" <lterrell@us.ibm.com>,
	"George Wilson" <gcwilson@us.ibm.com>
Subject: Re: [Qemu-devel] [RFC] Device sandboxing
Date: Fri, 9 Dec 2011 17:32:19 +0000	[thread overview]
Message-ID: <201112091732.20358.paul@codesourcery.com> (raw)
In-Reply-To: <1776059.g3E9io5gG3@sifl>

> 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

  reply	other threads:[~2011-12-09 17:32 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-07 18:25 [Qemu-devel] [RFC] Device sandboxing Corey Bryant
2011-12-07 18:48 ` Anthony Liguori
2011-12-07 19:32   ` Corey Bryant
2011-12-07 19:43     ` Anthony Liguori
2011-12-07 19:52       ` Michael Halcrow
2011-12-07 20:02       ` Corey Bryant
2011-12-07 20:54       ` Eric Paris
2011-12-08  9:40         ` Stefan Hajnoczi
2011-12-11 10:50           ` Dor Laor
2011-12-12 18:54             ` Will Drewry
2011-12-08  9:47     ` Stefan Hajnoczi
2011-12-08 14:39       ` Corey Bryant
2011-12-07 21:20   ` Paul Moore
2011-12-14 17:15     ` Serge E. Hallyn
2011-12-14 23:56       ` Paul Moore
2011-12-15 14:28         ` Corey Bryant
2011-12-15 15:14           ` Serge Hallyn
2011-12-15 15:35             ` Paul Moore
2011-12-15 16:05               ` Serge Hallyn
2011-12-08 21:51 ` Blue Swirl
2011-12-12 18:30   ` Corey Bryant
2011-12-09 16:17 ` Paul Brook
2011-12-09 16:34   ` Paul Moore
2011-12-09 17:32     ` Paul Brook [this message]
2011-12-09 17:49       ` Paul Moore
2011-12-09 18:46         ` Paul Brook
2011-12-09 18:50           ` Paul Moore
2011-12-09 18:59           ` Paul Brook
2011-12-09 19:17             ` Paul Moore
2011-12-10 19:39   ` Blue Swirl
2011-12-11  9:08   ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201112091732.20358.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=adlai@us.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=amit.shah@redhat.com \
    --cc=avi@redhat.com \
    --cc=coreyb@linux.vnet.ibm.com \
    --cc=eotubo@br.ibm.com \
    --cc=eparis@redhat.com \
    --cc=gcwilson@us.ibm.com \
    --cc=lterrell@us.ibm.com \
    --cc=mhalcrow@google.com \
    --cc=pmoore@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=radimkrcmar@hpx.cz \
    --cc=rmarwah@us.ibm.com \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).