[PATCH] arm64: ptrace: Fix seccomp of traced syscall -1 (NO_SYSCALL)
Will Deacon
will at kernel.org
Thu Feb 25 05:12:39 EST 2021
On Wed, Feb 24, 2021 at 02:48:05PM -0800, Kees Cook wrote:
> On Wed, Feb 24, 2021 at 02:49:20PM +0000, Sudeep Holla wrote:
> > On Mon, Jan 18, 2021 at 02:58:58AM +0000, Timothy Baldwin wrote:
> > > From c047f549699d31ed91d5ac0cadbcf76a02cd801e Mon Sep 17 00:00:00 2001
> > > From: Timothy E Baldwin<T.E.Baldwin99 at members.leeds.ac.uk>
> > > Date: Sat, 16 Jan 2021 15:18:54 +0000
> > > Subject: [PATCH] arm64: ptrace: Fix seccomp of traced syscall -1 (NO_SYSCALL)
> > >
> > > Since commit f086f67485c5 ("arm64: ptrace: add support for syscall
> > > emulation"), if system call number -1 is called and the process is being
> > > traced with PTRACE_SYSCALL, for example by strace, the seccomp check is
> > > skipped and -ENOSYS is returned unconditionally (unless altered by the
> > > tracer) rather than carrying out action specified in the seccomp filter.
> > >
> > > The consequence of this is that it is not possible to reliably strace
> > > a seccomp based implementation of a foreign system call interface in
> > > which r7/x8 is permitted to be -1 on entry to a system call.
> > >
> > > Also trace_sys_enter and audit_syscall_entry are skipped if a system
> > > call is skipped.
> > >
> > > Fix by removing the in_syscall(regs) check restoring the previous behaviour
> > > which is like AArch32, x86 (which uses generic code) and everything else.
> > >
> >
> > Ah, my fault. At the time of timing this I didn't test with seccomp and
> > also for some reason IIRC I had assumed the flags SYSCALL_{EMU,TRACE}
> > and seccomp calls are mutually exclusive and can't happen together.
> >
> > FWIW,
> > Reviewed-by: Sudeep Holla <sudeep.holla at arm.com>
> >
> > Also I ran some minimal tests I have, so
> > Tested-by: Sudeep Holla <sudeep.holla at arm.com>
> >
> > I have also asked Haibo Xu <Haibo.Xu at arm.com> who help me testing back then
> > to test again.
>
> Thanks for catching and fixing this! Does this pass the seccomp selftests?
>
> Reviewed-by: Kees Cook <keescook at chromium.org>
>
> Will, do you want to take this? I don't usually put the arch-specific
> seccomp bits through the seccomp tree.
Sure, I'll add it to the fixes pile. Thanks!
Will
More information about the linux-arm-kernel
mailing list