From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39211) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgMAI-0003Ou-Ei for qemu-devel@nongnu.org; Thu, 09 Apr 2015 19:47:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgMAE-0006PS-ED for qemu-devel@nongnu.org; Thu, 09 Apr 2015 19:47:18 -0400 From: Paul Moore Date: Thu, 09 Apr 2015 19:46:51 -0400 Message-ID: <2186908.62XuPTZaqu@sifl> In-Reply-To: References: <5525EB8B.5030501@suse.de> <4630773.If3mU9jhC7@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 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. Due to the nature of syscall filtering and the libseccomp API, the libseccomp library needs to maintain its own list of syscalls for each architecture/ABI; while this list is fairly static and doesn't often change, there are situations (e.g. adding a new ABI) that cause significant change and take some time to sort out. If you feel that you have a better design for libseccomp you are always welcome to submit patches, I'm happy to review code. I can't promise you there won't ever be bugs, but I think I've demonstrated that we take these things seriously and address the issues as we are made aware of them. Surely libseccomp isn't the only project to have bugs ;) > For the moment I think we should revert the "2.2 is OK on > ARM" QEMU configure patch for QEMU's 2.3 release, and go > back to the status-quo of "assume this only works on x86". The QEMU developers can do whatever they feel is best for the project; my main concern is maintaining libseccomp. -- paul moore security @ redhat