On Fri, Apr 6, 2012 at 4:24 PM, Andrew Morton [off-list ref] wrote:

On Thu, 29 Mar 2012 15:01:58 -0500
Will Drewry [off-list ref] wrote:

quoted

This change adds support for a new ptrace option, PTRACE_O_TRACESECCOMP,
and a new return value for seccomp BPF programs, SECCOMP_RET_TRACE.

When a tracer specifies the PTRACE_O_TRACESECCOMP ptrace option, the
tracer will be notified, via PTRACE_EVENT_SECCOMP, for any syscall that
results in a BPF program returning SECCOMP_RET_TRACE.  The 16-bit
SECCOMP_RET_DATA mask of the BPF program return value will be passed as
the ptrace_message and may be retrieved using PTRACE_GETEVENTMSG.

If the subordinate process is not using seccomp filter, then no
system call notifications will occur even if the option is specified.

If there is no tracer with PTRACE_O_TRACESECCOMP when SECCOMP_RET_TRACE
is returned, the system call will not be executed and an -ENOSYS errno
will be returned to userspace.

This change adds a dependency on the system call slow path.  Any future
efforts to use the system call fast path for seccomp filter will need to
address this restriction.


...

@@ -410,6 +411,15 @@ int __secure_computing_int(int this_syscall)

                      /* Let the filter pass back 16 bits of data. */
                      seccomp_send_sigsys(this_syscall, data);
                      goto skip;
+             case SECCOMP_RET_TRACE:
+                     /* Skip these calls if there is no tracer. */
+                     if (!ptrace_event_enabled(current, PTRACE_EVENT_SECCOMP))
+                             goto skip;
+                     /* Allow the BPF to provide the event message */
+                     ptrace_event(PTRACE_EVENT_SECCOMP, data);
+                     if (fatal_signal_pending(current))
+                             break;

I don't have all the patches applied here so the context is missing.
Perhaps tht would help me understand what this fatal_signal_pending()
test is doing here.  But an explanatory comment wouldn't hurt.

I'll add a comment along the lines of my answer below!

What *is* it here for, anyway?

The timely delivery of a fatal signal will silently block tracer event
notification.  By immediately terminating if a fatal signal is
pending, we avoid accidentally executing a system call that the tracer
did not approve of.

http://lxr.linux.no/linux+v3.3.1/kernel/signal.c#L1839

I can be more verbose, but hopefully that covers it well enough - thanks!