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

[Paul Moore]

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