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

[Serge Hallyn <serge.hallyn@canonical.com>]

Quoting Paul Moore (pmoore@redhat.com):
> On Thursday, December 15, 2011 09:14:11 AM Serge Hallyn wrote:
> > Quoting Corey Bryant (coreyb@linux.vnet.ibm.com):
> > > On 12/14/2011 06:56 PM, Paul Moore wrote:
> > > >On Wednesday, December 14, 2011 11:15:58 AM Serge E. Hallyn wrote:
> > > >>Hey Paul,
> > > >>
> > > >>just wondering, exactly which approache(s) are you prototyping?  Are
> > > >>you touching seccomp2?
> > > >
> > > >The decomposed approach as I felt (well, still do for that matter)
> > > >that the enhanced seccomp stuff could be put to even better use in a
> > > >decomposed mode of operation.
> > > >
> > > >However, earlier this week those of us involved in this effort were
> > > >strongly discouraged (this probably isn't the best term to use, but
> > > >there is a reason I'm a programmer and not an english student) from
> > > >pursuing the decomposed prototype further so work on it has dropped
> > > >off considerably.
> > > >
> > > >I still think it is worth pursuing, if for no other reason than to
> > > >answer questions that right now we can only answer with educated
> > > >guesses, but it is no longer my main focus.  If anyone else is
> > > >interested in this feel free to drop me some email and I can bring
> > > >you up to speed on the current status.
> >
> > Thanks, Paul.  I don't know for sure that I'll have time, but I'd
> > definately be interested in anything you have about current status
> > of that approach.  On my own I would've pursued the seccomp2 way
> > if only because I'll be doing the same for lxc, but if noone else
> > is following up on decomposition I might take a look over break.
> > And as you say, if the design ends up being maintaineable and with
> > acceptable performance overhead, I have no doubt it would be well
> > merged with seccomp2.
> 
> The current status of the prototype is that it is still largely incomplete; 
> most of the "how do I do this?" work is done, now it is just a matter of 
> coding.
> 
> I *think* I've identified all the function calls that the e1000 device 
> emulation makes into the core QEMU code as well as a good spot for forking, 
> most of the implementation is blank (lots of empty function bodies).  About 
> the only part of the implementation that currently has any substance to it is 
> the pipe based message passing and the code trickery that allows us to go from 
> straight functions calls to RPC/IPC.  Neither have been tested yet, and the 
> former isn't as elegant as I would like, but at least they all compile cleanly 
> ... ;)
> 
> As I said earlier, I still plan to allocate some time to working on this, but 
> much less than before.  I'll drop you another email, offlist, and if you've 
> got some interest/time in helping out you're more than welcome to join in.

Thanks, Paul.

-serge