From: Oleg Nesterov <oleg@redhat.com>
To: Max Ver <dudududumaxver@gmail.com>,
Andy Lutomirski <luto@amacapital.net>,
Kees Cook <kees@kernel.org>, Dmitry Levin <ldv@strace.io>
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
Will Drewry <wad@chromium.org>
Subject: Re: Process killed by seccomp looks live by tracer
Date: Sun, 8 Mar 2026 14:08:45 +0100 [thread overview]
Message-ID: <aa103dEXEqU4QlgZ@redhat.com> (raw)
In-Reply-To: <CABjJbF+vEwEr4fQo7zZwFtgPSJGM1veFnaaLrupOzaVDoi3hJg@mail.gmail.com>
On 03/06, Max Ver wrote:
>
> I suppose it's more reasonable for kernel to give a hint just after
> the syscall killed by seccomp at the fourth loop. So that we can know
> the syscall is rollbacked, or else we can only assume the syscall may
> succeed.
Perhaps you are right, but this is a question for seccomp experts...
Kees, Andy, what do you think?
Say, we can do something like
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -951,11 +951,20 @@ ptrace_get_syscall_info_seccomp(struct task_struct *child, struct pt_regs *regs,
return offsetofend(struct ptrace_syscall_info, seccomp.ret_data);
}
+// currently not exposed
+#define SECCOMP_MODE_DEAD (SECCOMP_MODE_FILTER + 1)
+
+static long xxx_get_error(struct task_struct *task, struct pt_regs *regs)
+{
+ return task->seccomp.mode == SECCOMP_MODE_DEAD
+ ? -EINTR : syscall_get_error(task, regs);
+}
+
static unsigned long
ptrace_get_syscall_info_exit(struct task_struct *child, struct pt_regs *regs,
struct ptrace_syscall_info *info)
{
- info->exit.rval = syscall_get_error(child, regs);
+ info->exit.rval = xxx_get_error(child, regs);
info->exit.is_error = !!info->exit.rval;
if (!info->exit.is_error)
info->exit.rval = syscall_get_return_value(child, regs);
but probably this is not a good solution.
Perhaps we can add a new "killed_by_seccomp" member into ptrace_syscall_info.exit ?
Or even add a new ptrace_syscall_info.op = PTRACE_SYSCALL_INFO_KILLED_BY_SECCOMP ?
Or change ptrace_report_syscall(PTRACE_EVENTMSG_SYSCALL_EXIT) to not report the event
if the tracee was killed by force_sig_seccomp(force_coredump => true) ?
Oleg.
>
> Oleg Nesterov <oleg@redhat.com> 于2026年3月6日周五 01:46写道:
> >
> > That said...
> >
> > __seccomp_filter() does
> >
> > case SECCOMP_RET_KILL_PROCESS:
> > ...
> > /* Show the original registers in the dump. */
> > syscall_rollback(current, current_pt_regs());
> >
> > /* Trigger a coredump with SIGSYS */
> > force_sig_seccomp(this_syscall, data, true);
> >
> > This means that after syscall_rollback() regs->ax == orig_ax, so
> > ptrace_get_syscall_info_exit() will always report .is_error == 0.
> >
> > And since force_sig_seccomp() uses force_coredump == true, SIGSYS
> > won't be reported (see the SA_IMMUTABLE check in get_signal()).
> >
> > Again, it is not that I think this wrong. But perhaps Kees and Andy
> > can take a look and confirm that this is what we actually want.
> >
> > Oleg.
next prev parent reply other threads:[~2026-03-08 13:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-04 10:51 Process killed by seccomp looks live by tracer Max Ver
2026-03-04 18:05 ` Kees Cook
2026-03-05 2:00 ` Max Ver
2026-03-05 14:49 ` Oleg Nesterov
2026-03-05 17:45 ` Oleg Nesterov
2026-03-06 2:55 ` Max Ver
2026-03-08 13:08 ` Oleg Nesterov [this message]
2026-03-22 13:40 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aa103dEXEqU4QlgZ@redhat.com \
--to=oleg@redhat.com \
--cc=bpf@vger.kernel.org \
--cc=dudududumaxver@gmail.com \
--cc=kees@kernel.org \
--cc=ldv@strace.io \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=wad@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.