From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9d9f-00024f-1G for qemu-devel@nongnu.org; Mon, 29 Jun 2015 13:47:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9d9b-0002b9-Qs for qemu-devel@nongnu.org; Mon, 29 Jun 2015 13:47:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9d9b-0002b4-D2 for qemu-devel@nongnu.org; Mon, 29 Jun 2015 13:47:35 -0400 Date: Mon, 29 Jun 2015 19:47:29 +0200 From: Andrew Jones Message-ID: <20150629174729.GC3146@hawk.localdomain> References: <1428670681-23032-1-git-send-email-peter.maydell@linaro.org> <17948100.v63oBISXG4@sifl> <20150629075017.GA4353@hawk.localdomain> <2221708.PWP4RFdTZC@sifl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2221708.PWP4RFdTZC@sifl> 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: Paul Moore Cc: Peter Maydell , Marcus Meissner , Karl-Philipp Richter , Patch Tracking , Riku Voipio , Alexander Graf , QEMU Developers , Eduardo Otubo , Andreas =?iso-8859-1?Q?F=E4rber?= On Mon, Jun 29, 2015 at 10:53:14AM -0400, Paul Moore wrote: > On Monday, June 29, 2015 09:50:17 AM Andrew Jones wrote: > > On Fri, Jun 26, 2015 at 04:26:22PM -0400, Paul Moore wrote: > > > Perhaps a stupid question, but you did verify that it is cacheflush that > > > is causing the problem? The seccomp filter code will emit a message to > > > syslog or the audit log, depending on your configuration, with the > > > syscall number. > > > > > > #./tools/scmp_sys_resolver -a arm cacheflush > > > 983042 > > > #./tools/scmp_sys_resolver -a arm 983042 > > > > I hadn't before (didn't know about the logging). I had determined the > > problem by running qemu in gdb. I just checked now though and confirmed > > it > > > > type=SECCOMP msg=audit(1435563996.731:2032): auid=1001 uid=1001 gid=1001 > > ses=157 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > > pid=27059 comm="qemu-system-arm" > > exe="/home/drjones/code/qemu/arm-softmmu/qemu-system-arm" sig=31 > > arch=40000028 syscall=983042 compat=0 ip=0xb6b43164 code=0x0 > > > > This log was generated even with the above patch applied to qemu. > > The only thing that comes to mind quickly is that the cacheflush() call is > being done by a thread that was created before the seccomp filter was loaded > into the kernel; although I believe you said you already checked that. Nope, I hadn't, but I have now. I went back to my friend gdb and set a couple breakpoints Breakpoint 1, seccomp_start () at qemu-seccomp.c:246 246 int rc = 0; (gdb) info threads Id Target Id Frame 2 Thread 0xb6a81130 (LWP 11351) "qemu-system-arm" 0xb6beebe0 in nanosleep () at ../sysdeps/unix/syscall-template.S:81 * 1 Thread 0xb6a83000 (LWP 11348) "qemu-system-arm" seccomp_start () at qemu-seccomp.c:246 (gdb) c Continuing. Breakpoint 2, __clear_cache () at ../../../libgcc/config/arm/lib1funcs.S:1348 1348 movw r7, #2 (gdb) info threads Id Target Id Frame 2 Thread 0xb6a81130 (LWP 11351) "qemu-system-arm" 0xb6beebe0 in nanosleep () at ../sysdeps/unix/syscall-template.S:81 * 1 Thread 0xb6a83000 (LWP 11348) "qemu-system-arm" __clear_cache () at ../../../libgcc/config/arm/lib1funcs.S:1348 (gdb) s 1349 movt r7, #0xf (gdb) 1354 mov r2, #0 (gdb) 1355 swi 0 (gdb) [Thread 0xb6a83000 (LWP 11348) exited] No unwaited-for children left. So we're calling __clear_cache from the same thread that called seccomp_start, and that thread dies the moment it calls the syscall. No other threads except id(2) at this time, which appears to be something created by __libc_start_main before main() runs. > > If you are using a recent kernel and libseccomp you can try enabling the > SCMP_FLTATR_CTL_TSYNC attribute to apply the filter to all running threads in > the process. > > rc = seccomp_attr_set(ctx, SCMP_FLTATR_CTL_TSYNC, 1); > if (rc) > /* error */ I tried this, but it error'ed out with rc == -95 (EOPNOTSUPP ?) My kernel version is 4.0.5-200.fc21.armv7hl+lpae Thanks, drew > > ... although that may have unintended consequences since threads which were > never filtered are not getting caught up in the seccomp filter. Although, the > current QEMU seccomp filter is so permissive it might not be a real concern. > > Anyway, (double) check the thread creation and seccomp_load() ordering. > > -- > paul moore > security @ redhat > >