Quoting Corey Bryant (cor...@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 (pmo...@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
