From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWtgq-0006TQ-WA for qemu-devel@nongnu.org; Mon, 29 Apr 2013 15:24:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWtgm-0002lE-BJ for qemu-devel@nongnu.org; Mon, 29 Apr 2013 15:24:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23434) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWtgm-0002l1-2U for qemu-devel@nongnu.org; Mon, 29 Apr 2013 15:24:40 -0400 From: Paul Moore Date: Mon, 29 Apr 2013 15:24:15 -0400 Message-ID: <1752415.n4lqG2Muub@sifl> In-Reply-To: <517EBE7D.4020100@linux.vnet.ibm.com> References: <517AC9E5.3050204@linux.vnet.ibm.com> <7515044.dYPbKXmJQB@sifl> <517EBE7D.4020100@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Qemu-devel] [RFC] Continuous work on sandboxing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Otubo Cc: qemu-devel@nongnu.org, Eric Paris On Monday, April 29, 2013 03:39:57 PM Eduardo Otubo wrote: > On 04/26/2013 06:07 PM, Paul Moore wrote: > > On Friday, April 26, 2013 03:39:33 PM Eduardo Otubo wrote: > > Also, looking a bit further ahead, it might be interesting to look at > > removing some of the arch dependent stuff in qemu-seccomp.c. The latest > > version of libseccomp should remove the need for many, if not all, of the > > arch specific #ifdefs and the next version of libseccomp will add support > > for x32 and ARM. > > Tell me more about this. You're saying I can remove the #ifdefs and keep > the lines like "{ SCMP_SYS(getresuid32), 241 }, " or address these > syscalls in another way? Yes. If you are using libseccomp 2.x you shouldn't need any of the #ifdefs in the seccomp_whitelist[] variable like there are at present. As long as you aren't using the *_exact() versions of the libseccomp APIs, which QEMU is not, the library will do the right thing for the current architecture: syscalls that don't exist will be ignored, those that need translation, e.g. socket() on x86, will be translated, and those that do exist normally will be handled normally. Anything else I would consider a bug in libseccomp. There is more to it if you are generating a seccomp filter to support multiple simultaneous architectures, e.g. x86 and x86_64, but that doesn't really apply with QEMU. -- paul moore security and virtualization @ redhat