Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Apr 2012 14:38:54 -0500
From: Will Drewry <wad@...omium.org>
To: Andrew Morton <akpm@...ux-foundation.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 Fri, Apr 6, 2012 at 4:24 PM, Andrew Morton <akpm@...ux-foundation.org> wrote:
> 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.

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!

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.