From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ygb32-0000CO-1C for qemu-devel@nongnu.org; Fri, 10 Apr 2015 11:40:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ygb2w-00041O-BO for qemu-devel@nongnu.org; Fri, 10 Apr 2015 11:40:47 -0400 Message-ID: <5527EEF8.7020209@suse.de> Date: Fri, 10 Apr 2015 17:40:40 +0200 From: =?windows-1252?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <5525EB8B.5030501@suse.de> <2186908.62XuPTZaqu@sifl> <2195639.EYFYKnq51Z@sifl> In-Reply-To: <2195639.EYFYKnq51Z@sifl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] seccomp breakage on arm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Moore Cc: Peter Maydell , Marcus Meissner , Karl-Philipp Richter , Riku Voipio , qemu-devel , Alexander Graf , qemu-ppc , Eduardo Otubo Am 10.04.2015 um 17:16 schrieb Paul Moore: > On Friday, April 10, 2015 01:44:32 PM Peter Maydell wrote: >> On 10 April 2015 at 00:46, Paul Moore wrote: >>> On Thursday, April 09, 2015 11:32:51 PM Peter Maydell wrote: >>>> On 9 April 2015 at 22:27, Paul Moore wrote: >>>>> Regardless, I think I see what the problem is, and if I'm correct i= t >>>>> affects time, umount, stime, alarm, utime, getrlimit, select, readd= ir, >>>>> mmap, socketcall, syscall, and ipc. I'm traveling at the moment so= a >>>>> patch may be a bit delayed, but I'll be sure to CC you on the fix i= n >>>>> case >>>>> you are able to do some testing. >>>> >>>> I was expecting seccomp 2.2.x to fix this by not requiring the >>>> existence in particular of *any* __NR_* define. >>> >>> I'm sorry to tell you that it doesn't work that way. >>> >>>> If you don't make the header cope with any of them being missing the= n >>>> this is going to continue to be fragile and liable to breakage on ne= w >>>> architectures into the future, I suspect :-( >>> >>> There are always going to be teething problems with support for new >>> architectures, especially ones that I do not personally have in front= of >>> me for testing. >> >> I appreciate the testing issue, but ARM is not a new architecture. >> 32-bit ARM has been around for decades, and 64-bit ARM now for >> several years. >=20 > ARM support is relatively new to libseccomp; I assumed we all recognize= d that=20 > ARM as an architecture/ABI has been around for some time. >=20 >> If in practice the only architecture you can test and support is i386/= x86_64 >> then it might be better to ensure you only build for that, so distros = don't=20 >> auto-build and ship unusable versions of the library ... {snip} >=20 > Both your tone and unsolicited advice have been noted. >=20 >> It's not clear to me how the current APIs QEMU is using would >> cope with trying to whitelist a new syscall that the system's >> libseccomp didn't know about; presumably SCMP_SYS(fancy_new_thing) >> will be a compile failure. Is there a runtime function we can >> call to pass it a string "fancy_new_thing" so we can get a runtime >> check on whether the syscall is supported by seccomp instead? >=20 > I would suggest looking at the libseccomp man pages and header file. =20 > Admittedly our documentation could be better (what project couldn't imp= rove on=20 > their documentation?), but it should answer your questions about runtim= e=20 > detection. >=20 > Also, if anyone even cares, I just committed a fix for the syscall prob= lem=20 > Andreas reported: >=20 > https://github.com/seccomp/libseccomp/commit/d1019115acdc8460c9a1f8a878= 768001a3c32431 Appreciated, I was already looking into patching our package. Maybe it helps your understanding that Peter is about to release QEMU v2.3.0, so everyone is on edge when build issues get found last minute. My main concern - that you apparently misunderstood - was whether this 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. Thanks, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=FCrnberg)