From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55264) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xm7Ia-0005HU-Pi for qemu-devel@nongnu.org; Wed, 05 Nov 2014 15:35:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xm7IU-0001VI-M6 for qemu-devel@nongnu.org; Wed, 05 Nov 2014 15:35:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xm7IU-0001V1-CY for qemu-devel@nongnu.org; Wed, 05 Nov 2014 15:35:18 -0500 From: Paul Moore Date: Wed, 05 Nov 2014 15:35:09 -0500 Message-ID: <2511814.5UZKhYSZ5W@sifl> In-Reply-To: References: <1415206067-8594-1-git-send-email-eduardo.otubo@profitbricks.com> <1730772.DqyRfLzkMU@sifl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Qemu-devel] [PATCH] seccomp: change configure to avoid arm 32 to break List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Eduardo Otubo , Philipp Gesang On Wednesday, November 05, 2014 08:08:06 PM Peter Maydell wrote: > On 5 November 2014 19:46, Paul Moore wrote: > > On Wednesday, November 05, 2014 05:08:20 PM Peter Maydell wrote: > >> On 5 November 2014 16:47, Eduardo Otubo wrote: > >> > Right now seccomp is breaking the compilation of Qemu on armv7l due > >> > to libsecomp current lack of support for this arch. This problem is > >> > already fixed on libseccomp upstream but no release date for that is > >> > scheduled to far. This patch disables support for seccomp on armv7l > >> > temporarily until libseccomp does a new release. Then I'll remove the > >> > hack and update libseccomp dependency on configure script. > >> > > >> > Related bug: https://bugs.launchpad.net/qemu/+bug/1363641 > > > > ... > > > >> (How are upstream proposing to fix this anyway? I couldn't > >> figure that out from the mailing list thread.) > > > > The problem was that the released version of libseccomp has some "holes" > > in > > the internal syscall table for 32-bit ARM with respect to all of the other > > supported architectures. The current libseccomp upstream has some > > additional tooling and checks to ensure that the different ABI syscall > > tables are kept in sync to prevent something like this from happening in > > the future. > > OK. So should we make QEMU say "if x86_64 or i386, require > seccomp 2.1 or better, else require 2.2 or better"? I would probably just limit QEMU/seccomp to x86_64 and x86. Once we have the new release that fixes everything we can start worrying about versions and different ABIs. > If our current source will build with seccomp 2.2 then that seems like a > better check to put in our configure script than a simple disabling of > the functionality on ARM hosts; it means that if distros end up > with QEMU 2.2 plus seccomp 2.2 the functionality won't be > unnecessarily disabled. (Please correct me if I have your > next-release numbering wrong!) Well, technically we don't have libseccomp v2.2 yet so I can't say for certain what it will look like and how it will behave. > > I'm more than happy to discuss how libseccomp handles the different > > architectures, but that's probably a bit off-topic for this thread. > > I guess the only thing that matters for us is that there wasn't > an API break required for the fix. Nope, the API is solid, just some internal fixes. -- paul moore security and virtualization @ redhat