From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9aQz-000353-Ao for qemu-devel@nongnu.org; Mon, 29 Jun 2015 10:53:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9aQv-0008Fm-39 for qemu-devel@nongnu.org; Mon, 29 Jun 2015 10:53:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51471) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9aQu-0008Ei-UH for qemu-devel@nongnu.org; Mon, 29 Jun 2015 10:53:17 -0400 From: Paul Moore Date: Mon, 29 Jun 2015 10:53:14 -0400 Message-ID: <2221708.PWP4RFdTZC@sifl> In-Reply-To: <20150629075017.GA4353@hawk.localdomain> References: <1428670681-23032-1-git-send-email-peter.maydell@linaro.org> <17948100.v63oBISXG4@sifl> <20150629075017.GA4353@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 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. 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 */ ... 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