[Top][All Lists]
[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
- Re: [Qemu-devel] [RFC] Device sandboxing, (continued)
- Re: [Qemu-devel] [RFC] Device sandboxing, Serge E. Hallyn, 2011/12/14
- Re: [Qemu-devel] [RFC] Device sandboxing, Paul Moore, 2011/12/14
- Re: [Qemu-devel] [RFC] Device sandboxing, Corey Bryant, 2011/12/15
- Re: [Qemu-devel] [RFC] Device sandboxing, Serge Hallyn, 2011/12/15
- Re: [Qemu-devel] [RFC] Device sandboxing, Paul Moore, 2011/12/15
- Re: [Qemu-devel] [RFC] Device sandboxing, Serge Hallyn, 2011/12/15
Re: [Qemu-devel] [RFC] Device sandboxing, Blue Swirl, 2011/12/08
Re: [Qemu-devel] [RFC] Device sandboxing, Paul Brook, 2011/12/09
- Re: [Qemu-devel] [RFC] Device sandboxing, Paul Moore, 2011/12/09
- Re: [Qemu-devel] [RFC] Device sandboxing,
Paul Brook <=
- Re: [Qemu-devel] [RFC] Device sandboxing, Paul Moore, 2011/12/09
- Re: [Qemu-devel] [RFC] Device sandboxing, Paul Brook, 2011/12/09
- Re: [Qemu-devel] [RFC] Device sandboxing, Paul Moore, 2011/12/09
- Re: [Qemu-devel] [RFC] Device sandboxing, Paul Brook, 2011/12/09
- Re: [Qemu-devel] [RFC] Device sandboxing, Paul Moore, 2011/12/09
Re: [Qemu-devel] [RFC] Device sandboxing, Blue Swirl, 2011/12/10
Re: [Qemu-devel] [RFC] Device sandboxing, Avi Kivity, 2011/12/11