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

[Paul Moore]

On Friday, June 26, 2015 06:03:18 PM Andrew Jones wrote:
> On Tue, Jun 16, 2015 at 02:16:03PM +0100, Peter Maydell wrote:
> > On 16 June 2015 at 14:12, Andrew Jones <address@hidden> wrote:
> > > Can we now revert this revert, along with bumping the non-x86 arch
> > > atleast-version to v2.2.1
> > 
> > Probably. I suggest you submit a patch and test it on the
> > relevant architectures and seccomp versions.
> 
> I don't see any problems with the light testing (booting a guest)
> I've done on my mustang, but AArch64 worked with libseccomp 2.2.0
> too. So I dusted off my Midway (updated to Fedora 21 that has
> libseccomp 2.2.1 packaged), and gave it a try, but unfortunately
> it still doesn't work...
> 
> I found that we needed to add another syscall to the whitelist;
> the arm-private 'cacheflush', as it's used by __builtin___clear_cache.
> And, from libseccomp's git history it appears that syscall is known
> 
> commit a710a2d246bdc73ba77e3ff5624e790688cc51fd
> Author: Paul Moore <address@hidden>
> Date:   Wed May 6 12:05:45 2015 -0400
> 
>     arm: add some missing syscalls
> 
>     Add the following syscalls to the ARM arch/ABI and update the syscall
>     validation script.
> 
>      * breakpoint()
>      * cacheflush()
>      * usr26()
>      * usr32()
>      * set_tls()
> 
>     Reported-by: Purcareata Bogdan <address@hidden>
>     Signed-off-by: Paul Moore <address@hidden>
> 
> 
> And also appears to be in 2.2.1
> $ git describe a710a2d246bdc73ba77e3ff5624e790688cc51fd
> v2.2.0-10-ga710a2d246bdc
> 
> However the qemu thread that makes that syscall still dies, even
> with this patch
> 
> diff --git a/qemu-seccomp.c b/qemu-seccomp.c
> index f9de0d3390feb..33644a4e3c3d3 100644
> --- a/qemu-seccomp.c
> +++ b/qemu-seccomp.c
> @@ -237,7 +237,8 @@ static const struct QemuSeccompSyscall
> seccomp_whitelist[] = {
>      { SCMP_SYS(fadvise64), 240 },
>      { SCMP_SYS(inotify_init1), 240 },
>      { SCMP_SYS(inotify_add_watch), 240 },
> -    { SCMP_SYS(mbind), 240 }
> +    { SCMP_SYS(mbind), 240 },
> +    { SCMP_SYS(cacheflush), 240 },
>  };
> 
>  int seccomp_start(void)
> 
> 
> Paul, can you help me figure out what I'm missing?

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

-- 
paul moore
security @ redhat