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

[Paul Moore]

On Thursday, December 15, 2011 09:14:11 AM Serge Hallyn wrote:
> Quoting Corey Bryant (address@hidden):
> > 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.

-- 
paul moore
virtualization @ redhat