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

[Paul Moore]

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