On Fri, Apr 6, 2012 at 4:24 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 29 Mar 2012 15:01:58 -0500 > Will Drewry <wad@xxxxxxxxxxxx> wrote: > >> 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! -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
