Re: [Qemu-devel] [PATCH for-2.3] Revert seccomp tests that allow it to be used on non-x86 architectures

[Andrew Jones <drjones@redhat.com>]

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
> 
>