[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 Apr 2012 14:24:23 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Will Drewry <wad@...omium.org>
Cc: linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org,
linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
kernel-hardening@...ts.openwall.com, netdev@...r.kernel.org,
x86@...nel.org, arnd@...db.de, davem@...emloft.net, hpa@...or.com,
mingo@...hat.com, oleg@...hat.com, peterz@...radead.org,
rdunlap@...otime.net, mcgrathr@...omium.org, tglx@...utronix.de,
luto@....edu, eparis@...hat.com, serge.hallyn@...onical.com,
djm@...drot.org, scarybeasts@...il.com, indan@....nu, pmoore@...hat.com,
corbet@....net, eric.dumazet@...il.com, markus@...omium.org,
coreyb@...ux.vnet.ibm.com, keescook@...omium.org, jmorris@...ei.org
Subject: Re: [PATCH v17 13/15] ptrace,seccomp: Add PTRACE_SECCOMP support
On Thu, 29 Mar 2012 15:01:58 -0500
Will Drewry <wad@...omium.org> 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.
What *is* it here for, anyway?
> + return 0;
> case SECCOMP_RET_ALLOW:
> return 0;
> case SECCOMP_RET_KILL:
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
