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

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

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:
> >>Quoting Paul Moore (pmoore@redhat.com):
> >>>On Wednesday, December 07, 2011 12:48:16 PM Anthony Liguori wrote:
> >>>>On 12/07/2011 12:25 PM, Corey Bryant 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:
> >>>>To be perfectly honest, I think prototyping and measuring
> >>>>performance is going to be the only way to figure out the right
> >>>>approach here.>
> >>>Agreed.  I'm currently working on a prototype to play around with some
> >>>of the ideas discussed in this thread.  As soon as it is functional
> >>>I'll send a pointer/patches/etc. to the list.
> >>
> >>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.

> >As far as the enhanced seccomp patches for QEMU, I believe Corey said that IBM
> >was starting work on a prototype based on the patches that Will posted earlier
> >this year.  I don't expect this change to be very substantial, the hard part
> >will be determining the syscall filter and maintaining it over time.
> >
> 
> Paul covered the current state of affairs above so I won't expand on
> that much.  One of the major concerns from the QEMU community
> revolved around the maintenance complexity introduced by decomposing
> QEMU into separate processes, and that patches doing so were
> unlikely to be accepted.
> 
> With that in mind we're going to pursue a single process mode 2
> approach.  We'll put together a trivial prototype for evaluation
> purposes.  Like Paul mentioned, one of the complex parts is
> determining the correct call parameter filters, and there will be
> tweaking required as new syscalls/parameters are introduced in the
> future.  But the biggest hurdle is getting mode 2 patches into the
> mainline kernel, which has been an unsuccessful effort for a few
> years now.

I might be wrong but I think that's a bit overly pessimistic :)  Pretty
sure it's only been a few months.  Compared to some other things like
checkpoint/restart and user namespaces, it's positively on a fast track.
And if qemu demonstrates true value, that can only help.

thanks,
-serge