From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33604) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgafY-0000lm-Uk for qemu-devel@nongnu.org; Fri, 10 Apr 2015 11:16:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgafU-0001ft-Lg for qemu-devel@nongnu.org; Fri, 10 Apr 2015 11:16:32 -0400 From: Paul Moore Date: Fri, 10 Apr 2015 11:16:22 -0400 Message-ID: <2195639.EYFYKnq51Z@sifl> In-Reply-To: References: <5525EB8B.5030501@suse.de> <2186908.62XuPTZaqu@sifl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Qemu-devel] seccomp breakage on arm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Marcus Meissner , Karl-Philipp Richter , Riku Voipio , Alexander Graf , qemu-devel , qemu-ppc , Eduardo Otubo , Andreas =?ISO-8859-1?Q?F=E4rber?= 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 it > >> > affects time, umount, stime, alarm, utime, getrlimit, select, readdir, > >> > 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 in > >> > 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 then > >> this is going to continue to be fragile and liable to breakage on new > >> 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. ARM support is relatively new to libseccomp; I assumed we all recognized that ARM as an architecture/ABI has been around for some time. > 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 > auto-build and ship unusable versions of the library ... {snip} Both your tone and unsolicited advice have been noted. > 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? I would suggest looking at the libseccomp man pages and header file. Admittedly our documentation could be better (what project couldn't improve on their documentation?), but it should answer your questions about runtime detection. Also, if anyone even cares, I just committed a fix for the syscall problem Andreas reported: https://github.com/seccomp/libseccomp/commit/d1019115acdc8460c9a1f8a878768001a3c32431 -- paul moore security @ redhat