Re: [PATCH v2 1/2] ptrace: PTRACE_SET_SYSCALL_INFO syscall skipping support

[Renzo Davoli]

There is a problem on MIPS:
https://sashiko.dev/#/patchset/20260704142643.692754-1-renzo%40cs.unibo.it

It appears that on MIPS the feature of skipping a system call by setting its
number to -1 does not work correctly when transitioning from _ENTRY to _EXIT:
the system call return value is overwritten.

PTRACE_EVENT_SECCOMP, however, has an explicit UAPI specification stating that
setting the system call number to a negative value suppresses the system call.

Moreover, kernel/ptrace.c contains the following comment:
/*
 * If the syscall number is set to -1, setting syscall arguments is not
 * just pointless, it would also clobber the syscall return value on
 * those architectures that share the same register both for the first
 * argument of syscall and its return value.
 */
Thus, PTRACE_EVENT_SECCOMP is explicitly designed to preserve the system call
return value when the system call is skipped.

By contrast, for PTRACE_SYSCALL syscall-entry stops, the man page only states
that the tracer may modify the system call number. It does not specify that
assigning a negative value must suppress the system call and preserve the
return value across all architectures, even though many architectures implement
exactly this behavior.

At this point I see two possible approaches:

* fix the MIPS implementation (and audit, and possibly fix, the other
  architectures as well);

* revert to the original proposal and allow the "skip syscall" feature only for
  PTRACE_EVENT_SECCOMP, i.e. permit PTRACE_SET_SYSCALL_INFO to transform only
  PTRACE_SYSCALL_INFO_SECCOMP stops into PTRACE_SYSCALL_INFO_EXIT stops.

I would prefer the latter approach. I am concerned that changing the ptrace
implementation in each architecture may introduce subtle regressions or other
unintended side effects.

In my opinion, seccomp-based syscall tracing is also the more powerful and
flexible model compared to the traditional PTRACE_SYSCALL entry/exit mechanism.

Support for system call suppression from PTRACE_SYSCALL_INFO_ENTRY can always
be added later if and when a real use case arises. That would also provide an
opportunity to audit the behavior of all supported architectures and, if
necessary, make the semantics of negative system call numbers consistent across
architectures.

	renzo