qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Device sandboxing


From: Paul Brook
Subject: Re: [Qemu-devel] [RFC] Device sandboxing
Date: Fri, 9 Dec 2011 17:32:19 +0000
User-agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )

> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]