From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:45025)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pmoore@redhat.com>) id 1YghrO-00045w-5D
	for qemu-devel@nongnu.org; Fri, 10 Apr 2015 18:57:15 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pmoore@redhat.com>) id 1YghrK-0003lO-53
	for qemu-devel@nongnu.org; Fri, 10 Apr 2015 18:57:14 -0400
From: Paul Moore <pmoore@redhat.com>
Date: Fri, 10 Apr 2015 18:56:44 -0400
Message-ID: <1595331.sxpEq01QmG@sifl>
In-Reply-To: <5527EEF8.7020209@suse.de>
References: <5525EB8B.5030501@suse.de> <2195639.EYFYKnq51Z@sifl>
	<5527EEF8.7020209@suse.de>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Subject: Re: [Qemu-devel] seccomp breakage on arm
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Andreas =?ISO-8859-1?Q?F=E4rber?= <afaerber@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>, Marcus Meissner <meissner@suse.de>, Karl-Philipp Richter <krichter722@aol.de>, Riku Voipio <riku.voipio@iki.fi>, qemu-devel <qemu-devel@nongnu.org>, Alexander Graf <agraf@suse.de>, qemu-ppc <qemu-ppc@nongnu.org>, Eduardo Otubo <eduardo.otubo@profitbricks.com>

On Friday, April 10, 2015 05:40:40 PM Andreas F=E4rber wrote:
> My main concern - that you apparently misunderstood - was whether thi=
s
> is a QEMU or a libseccomp issue. If it's on libseccomp's side then it=
's
> less urgent for QEMU and any new configure checks are just candy IMO.=


My opinion is that the 32-bit ARM build issue you described is a libsec=
comp=20
bug (see the bug fix I sent a few hours ago); QEMU's usage of libseccom=
p is=20
perfectly reasonable.  That said, the libseccomp bug clearly affected Q=
EMU in=20
a bad way.  Making matters worse is that the problem wasn't caught unti=
l late=20
in the QEMU release process, nobody likes surprises like this.

We've corrected the issue in libseccomp, and it looks like the QEMU fol=
ks are=20
reverting ARM/seccomp support so I think we've resolved this for the im=
mediate=20
future.  Long term I think the libseccomp project can look at adding so=
me=20
additional automated tests so these issues will be caught at build/pack=
aging=20
time, further, I think the QEMU project can restore ARM/seccomp support=
 in the=20
next release and look at its own testing procedures to understand why t=
his=20
issue wasn't caught earlier as well.

--=20
paul moore
security @ redhat