From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbCK7-0006cF-AV for qemu-devel@nongnu.org; Thu, 15 Dec 2011 09:30:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbCK1-0000y8-AR for qemu-devel@nongnu.org; Thu, 15 Dec 2011 09:30:15 -0500 Received: from e2.ny.us.ibm.com ([32.97.182.142]:50570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbCK1-0000xC-7Z for qemu-devel@nongnu.org; Thu, 15 Dec 2011 09:30:09 -0500 Received: from /spool/local by e2.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Dec 2011 09:30:05 -0500 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBFESsRv333366 for ; Thu, 15 Dec 2011 09:28:55 -0500 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBFESi0C011219 for ; Thu, 15 Dec 2011 07:28:45 -0700 Message-ID: <4EEA0419.1000201@linux.vnet.ibm.com> Date: Thu, 15 Dec 2011 09:28:41 -0500 From: Corey Bryant MIME-Version: 1.0 References: <4EDFAF91.4070904@linux.vnet.ibm.com> <1660519.SAi13A61Ja@sifl> <20111214171558.GA27963@sergelap> <1780929.Tikc7pfcfH@sifl> In-Reply-To: <1780929.Tikc7pfcfH@sifl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Device sandboxing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Moore Cc: "Serge E. Hallyn" , Stefan Hajnoczi , Michael Halcrow , qemu-devel@nongnu.org, Eric Paris , Ashley D Lai , Avi Kivity , Richa Marwaha , Amit Shah , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Eduardo Terrell Ferrari Otubo , Lee Terrell , George Wilson 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. > > 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. -- Regards, Corey