Re: [PATCH v5 0/2] PTRACE_SET_SYSCALL_INFO: add support for seccomp syscall skipping

[Oleg Nesterov <oleg@redhat.com>]

Michal, thanks for your comments.

On 07/10, Michal Suchánek wrote:
>
> this will not work at least on powerpc, and possibly s390x.
>
> On these architectures the syscall number and the syscall return value
> share the same register.

You know, PTRACE_{GET,SET}_SYSCALL_INFO code is not is not trivial in
that it tries to provide the arch-neutral API to user-space, and thus
we need help from experts who understand the non-x86 low level details.

So perhaps you can provide more details to explain whats wrong with ppc?
I too can't understand the problem.

> However, the tracing hook in seccomp does not return anything, in
> particular it does not change the return value of __secure_computing().
>
>                 /* Allow the BPF to provide the event message */
>                 ptrace_event(PTRACE_EVENT_SECCOMP, data);

Sorry, I don't understand. __secure_computing(SECCOMP_RET_TRACE)
checks syscall_get_nr() checks syscall_get_nr() and returns -1 if
this_syscall < 0.

Note also SECCOMP_RET_USER_NOTIF, this path can skip syscall and it
does syscall_set_return_value(). But yes, this path doesn't use
syscall_set_nr().

> Other ways to rework the setting of the return value are possible. eg.
> it was suggested to add a special field to pt_regs to hold the syscall
> return value, and only copy it to the register at syscall exit.

Or we can add PTRACE_SKIP_SYSCALL set by ptrace_set_syscall_info() and
checked/cleared by ptrace_report_syscall_entry(). Although I'd like to
avoid this at least right now.

In short. Thanks again, but I can't understand your email. Please add
more details?

Oleg.