From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbD0u-00027p-6l for qemu-devel@nongnu.org; Thu, 15 Dec 2011 10:14:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbD0o-0002mi-4J for qemu-devel@nongnu.org; Thu, 15 Dec 2011 10:14:28 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:57664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbD0n-0002mW-Tl for qemu-devel@nongnu.org; Thu, 15 Dec 2011 10:14:22 -0500 Date: Thu, 15 Dec 2011 09:14:11 -0600 From: Serge Hallyn Message-ID: <20111215151411.GB3287@sergelap> References: <4EDFAF91.4070904@linux.vnet.ibm.com> <1660519.SAi13A61Ja@sifl> <20111214171558.GA27963@sergelap> <1780929.Tikc7pfcfH@sifl> <4EEA0419.1000201@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EEA0419.1000201@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [RFC] Device sandboxing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Corey Bryant Cc: Stefan Hajnoczi , Michael Halcrow , qemu-devel@nongnu.org, Eric Paris , Paul Moore , Ashley D Lai , Avi Kivity , Richa Marwaha , Amit Shah , Radim =?utf-8?B?S3LEjW3DocWZ?= , Eduardo Terrell Ferrari Otubo , Lee Terrell , George Wilson 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