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
