Kees Cook <keesc...@chromium.org> writes: > On Fri, Sep 11, 2020 at 03:10:12PM -0300, Thadeu Lima de Souza Cascardo wrote: ... >> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c >> b/tools/testing/selftests/seccomp/seccomp_bpf.c >> index 7a6d40286a42..0ddc0846e9c0 100644 >> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c >> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c >> @@ -1916,10 +1957,15 @@ void tracer_ptrace(struct __test_metadata >> *_metadata, pid_t tracee, >> EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY >> : PTRACE_EVENTMSG_SYSCALL_EXIT, msg); >> >> - if (!entry) >> + if (!entry && !variant) >> return; >> >> - nr = get_syscall(_metadata, tracee); >> + if (entry) >> + nr = get_syscall(_metadata, tracee); >> + else if (variant) >> + nr = variant->syscall_nr; >> + if (variant) >> + variant->syscall_nr = nr; > > So, to be clear this is _only_ an issue for the ptrace side of things, > yes? i.e. seccomp's setting of the return value will correct stick?
Yes. There's a comment which (hopefully) explains the difference here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/ptrace/ptrace.c?commit=ab29a807a7ddaa7c84d2f4cb8d29e74e33759072#n239 Which says: static int do_seccomp(struct pt_regs *regs) { if (!test_thread_flag(TIF_SECCOMP)) return 0; /* * The ABI we present to seccomp tracers is that r3 contains * the syscall return value and orig_gpr3 contains the first * syscall parameter. This is different to the ptrace ABI where * both r3 and orig_gpr3 contain the first syscall parameter. */ regs->gpr[3] = -ENOSYS; cheers
