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