From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9yuf-0003VD-RT for qemu-devel@nongnu.org; Tue, 30 Jun 2015 13:01:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9yua-0004mN-8j for qemu-devel@nongnu.org; Tue, 30 Jun 2015 13:01:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58292) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9yua-0004kR-4J for qemu-devel@nongnu.org; Tue, 30 Jun 2015 13:01:32 -0400 From: Paul Moore Date: Tue, 30 Jun 2015 13:01:29 -0400 Message-ID: <2877592.aNXnatIRsp@sifl> In-Reply-To: <20150630083934.GA3016@hawk.localdomain> References: <1428670681-23032-1-git-send-email-peter.maydell@linaro.org> <4050262.AavIzuNMzJ@sifl> <20150630083934.GA3016@hawk.localdomain> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Qemu-devel] [PATCH for-2.3] Revert seccomp tests that allow it to be used on non-x86 architectures List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Jones Cc: Peter Maydell , Marcus Meissner , Eduardo Otubo , Patch Tracking , Riku Voipio , Alexander Graf , QEMU Developers , Karl-Philipp Richter , Andreas =?ISO-8859-1?Q?F=E4rber?= On Tuesday, June 30, 2015 10:39:34 AM Andrew Jones wrote: > On Mon, Jun 29, 2015 at 04:24:55PM -0400, Paul Moore wrote: > > Hmm, so either the kernel is screwing up with the seccomp filter for this > > particular syscall (unlikely) or libseccomp is screwing up the filter > > creation (more likely). I don't have an ARM system handy at the moment, > > but could you use the seccomp_export_pfc() and seccomp_export_bpf() > > functions to dump the PFC/BPF filter code to a file and send it out? > > Attached Thanks. > I looked at the pfc file and compared all the syscalls in it vs. the list > in qemu-seccomp.c. The pfc file is missing cacheflush, and has an 'UNKNOWN' > instead. Yeah, the associated syscall number is showing -10104 which is the pseudo syscall number for architectures that don't support cacheflush(). That is obviously wrong > Also, I think there may be another problem with the filter (or pfc) > generation. Several of the syscalls have weird syscall numbers. For > example, I would expect mmap to be 90, but instead it's -10181. That is intentional. According to the Linux kernel sources mmap() isn't defined for 32-bit ARM EABI so you are seeing libseccomp's pseudo syscall number for mmap(). > And, since there was something weird, and not related to cacheflush, in the > arm32 pfc, I decided to check it on my mustang too. The output there gets > "cacheflush" for the name instead of UNKNOWN, but has the same weird > number (-10104) that the midway has. It also has several other weird > numbers. The output from the mustang is in the attached tarball as well. I would expect aarch64 to have a pseudo syscall number for cacheflush() as that syscall isn't defined for 64-bit ARM. What I don't understand is why libseccomp doesn't recognize cacheflush() in this particular case. I'm starting to wonder if the 32-bit ARM build system didn't have __NR_cacheflush defined in the system headers; that might explain some of the behavior. Could you check your system to see if it has __NR_cacheflush defined (try /usr/include/asm/unistd.h)? If it does, could you try rebuilding the libseccomp package on your system and seeing if it resolves the problem? -- paul moore security @ redhat