Re: [PATCH 1/5] ptrace: add PTRACE_SYSCALL_INFO_SECCOMP_SKIP

["Dmitry V. Levin" <ldv@strace.io>]

On Thu, Jul 02, 2026 at 01:31:08PM +0200, Oleg Nesterov wrote:
> On 07/02, Dmitry V. Levin wrote:
> > On Thu, Jul 02, 2026 at 11:58:14AM +0200, Oleg Nesterov wrote:
> > [...]
> > > @@ -1047,6 +1069,11 @@ ptrace_set_syscall_info_entry(struct task_struct *child, struct pt_regs *regs,
> > >  	if (nr != info->entry.nr)
> > >  		return -ERANGE;
> > >
> > > +	syscall_set_nr(child, regs, nr);
> > > +	if (nr == -1)
> > > +		return __set_syscall_info_exit(child, regs,
> > > +						info->entry.rval, info->entry.is_error);
> >
> > The kernel shouldn't suddenly start interpreting info->entry.rval and
> > info->entry.is_error because the current users of this interface are not
> > aware that the kernel might be doing it.  If we want to extend
> > PTRACE_SYSCALL_INFO_ENTRY/PTRACE_SYSCALL_INFO_SECCOMP this way, we would
> > have to require setting a flag in info->flags signalling the kernel that
> > the user requests this new behaviour.
> 
> Ah. I forgot to mention that (obviously) this is a user-visible change,
> and a new flag in info->flags will be safer. Of course.
> 
> Or we can define a special SKIP_AND_SET_RVAL value for info->entry.nr.
> 
> But I am just curious, will this change (without new flag) actually break
> strace? What does strace do when it uses PTRACE_SYSCALL_INFO_ENTRY with
> info->entry.nr == -1?

When strace is used for syscall tampering, it first performs a quick
PTRACE_SET_SYSCALL_INFO runtime check - very similar to the test in
tools/testing/selftests/ptrace/set_syscall_info.c.  If this check fails,
strace assumes the PTRACE_SET_SYSCALL_INFO interface is unavailable.

Changing the PTRACE_SYSCALL_INFO_ENTRY behavior this way would cause that
initialization check to fail, meaning strace would gracefully fall back
and not use the interface at all.


-- 
ldv