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

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

[Oleg Nesterov]

Oh... I know nothing about mips.

Add Thomas. Thomas could you help? See the question below.

OK, lets only allow the _SECCOMP -> _EXIT transition for now.
But will it work on MIPS?

grep, grep... So arch/mips/ has

	static inline void syscall_set_return_value(struct task_struct *task,
						    struct pt_regs *regs,
						    int error, long val)
	{
		if (error) {
			regs->regs[2] = -error;
			regs->regs[7] = 1;
		} else {
			regs->regs[2] = val;
			regs->regs[7] = 0;
		}
	}

	static inline void syscall_set_nr(struct task_struct *task,
					  struct pt_regs *regs,
					  int nr)
	{
		/*
		 * New syscall number has to be assigned to regs[2] because
		 * it is loaded from there unconditionally after return from
		 * syscall_trace_enter() invocation.
		 *
		 * Consequently, if the syscall was indirect and nr != __NR_syscall,
		 * then after this assignment the syscall will cease to be indirect.
		 */
		task_thread_info(task)->syscall = regs->regs[2] = nr;
	}

I have no idea. But at least ptrace_set_syscall_info_exit(skip => true)
must do syscall_set_nr(-1) before syscall_set_return_value(), otherwise
the value assigned to regs[2] will be lost.

-------------------------------------------------------------------------------
Now the question. To simplify, suppose we need something like

	void skip_syscall_and_set_return_value(task, regs, retval)
	{
		syscall_set_nr(task, regs, -1);
		syscall_set_return_value(task, regs, 0, retval);
	}

which can be used by debugger when the tracee sleeps in ptrace_report_syscall_entry().

However, arch/mips/kernel/ptrace.c:syscall_trace_enter() does:

	ptrace_report_syscall_entry(regs);

	if (current_thread_info()->syscall < 0)
		syscall_set_return_value(current, regs, -ENOSYS, 0);

and this means that this func won't work on MIPS. Is it possible to make it
work somehow? May be we can abuse regs->regs[7] somehow to detect the case when
syscall_set_return_value() was called by debugger and avoid the unconditional
-ENOSYS ?

Oleg.

On 07/05, Renzo Davoli wrote:
>
> 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
>

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

[Renzo Davoli]

On Sun, Jul 05, 2026 at 04:38:05PM +0200, Oleg Nesterov wrote:
> OK, lets only allow the _SECCOMP -> _EXIT transition for now.
done in v3.
> But will it work on MIPS?

IMHO yes, it will (would).

PTRACE_EVENT_SECCOMP follows a different flow, it does not call ptrace_report_syscall_entry.

As a confirmation sashiko on v3 (allowing _SECCOMP -> _EXIT only) lists no more regressions.

happy hacking
	renzo

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

[Oleg Nesterov]

On 07/07, Renzo Davoli wrote:
>
> On Sun, Jul 05, 2026 at 04:38:05PM +0200, Oleg Nesterov wrote:
> > OK, lets only allow the _SECCOMP -> _EXIT transition for now.
> done in v3.
> > But will it work on MIPS?
>
> IMHO yes, it will (would).

Agreed, it is not that I think it won't... but it would be nice to have an ACK
from arch/mips maintainers. syscall_trace_enter() is called from MIPS asm code
which I obviously can't understand.

Nevermind. Let me ack your V3.

Oleg.

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

[Thomas Bogendoerfer]

On Tue, Jul 07, 2026 at 06:04:56PM +0200, Oleg Nesterov wrote:
> On 07/07, Renzo Davoli wrote:
> >
> > On Sun, Jul 05, 2026 at 04:38:05PM +0200, Oleg Nesterov wrote:
> > > OK, lets only allow the _SECCOMP -> _EXIT transition for now.
> > done in v3.
> > > But will it work on MIPS?
> >
> > IMHO yes, it will (would).
> 
> Agreed, it is not that I think it won't... but it would be nice to have an ACK
> from arch/mips maintainers. syscall_trace_enter() is called from MIPS asm code
> which I obviously can't understand.

I'm looking into it, but spare time short at the moment...

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

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

[Thomas Bogendoerfer]

On Tue, Jul 07, 2026 at 06:04:56PM +0200, Oleg Nesterov wrote:
> On 07/07, Renzo Davoli wrote:
> >
> > On Sun, Jul 05, 2026 at 04:38:05PM +0200, Oleg Nesterov wrote:
> > > OK, lets only allow the _SECCOMP -> _EXIT transition for now.
> > done in v3.
> > > But will it work on MIPS?
> >
> > IMHO yes, it will (would).
> 
> Agreed, it is not that I think it won't... but it would be nice to have an ACK
> from arch/mips maintainers. syscall_trace_enter() is called from MIPS asm code
> which I obviously can't understand.

current code works for SECCOMP and with below untested change it should
work for PTRACE_SYSCALL, too.

Thomas.

diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c
index 3f4c94c88124..87102a03b6ea 100644
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -1321,8 +1321,12 @@ long arch_ptrace(struct task_struct *child, long request,
  */
 asmlinkage long syscall_trace_enter(struct pt_regs *regs)
 {
+	long syscall;
+
 	user_exit();
 
+	syscall = current_thread_info()->syscall;
+
 	if (test_thread_flag(TIF_SYSCALL_TRACE)) {
 		if (ptrace_report_syscall_entry(regs))
 			return -1;
@@ -1342,7 +1346,7 @@ asmlinkage long syscall_trace_enter(struct pt_regs *regs)
 	 * Negative syscall numbers are mistaken for rejected syscalls, but
 	 * won't have had the return value set appropriately, so we do so now.
 	 */
-	if (current_thread_info()->syscall < 0)
+	if (syscall < 0)
 		syscall_set_return_value(current, regs, -ENOSYS, 0);
 	return current_thread_info()->syscall;
 }

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]