LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Eric Paris <eparis@parisplace.org>
Cc: Eric Paris <eparis@redhat.com>,
	linux-kernel@vger.kernel.org, mingo@elte.hu, agl@google.com,
	fweisbec@gmail.com, tzanussi@gmail.com,
	Jason Baron <jbaron@redhat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	2nddept-manager@sdl.hitachi.co.jp
Subject: Re: Using ftrace/perf as a basis for generic seccomp
Date: Wed, 02 Feb 2011 21:14:41 +0900	[thread overview]
Message-ID: <4D494AB1.1040508@hitachi.com> (raw)
In-Reply-To: <AANLkTi=tmzKqLL30q9Mq+9u7s-M3sG2-MKz7pUJ1R08Z@mail.gmail.com>

Hi Eric,

(2011/02/01 23:58), Eric Paris wrote:
> On Wed, Jan 12, 2011 at 4:28 PM, Eric Paris <eparis@redhat.com> wrote:
>> Some time ago Adam posted a patch to allow for a generic seccomp
>> implementation (unlike the current seccomp where your choice is all
>> syscalls or only read, write, sigreturn, and exit) which got little
>> traction and it was suggested he instead do the same thing somehow using
>> the tracing code:
>> http://thread.gmane.org/gmane.linux.kernel/833556

Hm, interesting idea :)
But why would you like to use tracing code? just for hooking?

>> The actual method that this could be achieved was apparently left as an
>> exercise for the reader.  Since I'd like to do something similar (and
>> actually basically reimplemented Adam's code before I found this thread)
>> I guess that makes me the reader.  I've never touched
>> perf/ftrace/whatever so I'm not even knowledgeably enough to ask good
>> questions so please, try to talk to me like a 2 year old.

OK, I'll try to explain;

Ftrace/perf syscall event tracing is based on syscall tracepoints
(sys_enter and sys_exit) which are implemented as a special hook
requiring TIF_SYSCALL_TRACEPOINT.

--<arch/x86/kernel/ptrace.c>--
asmregparm long syscall_trace_enter(struct pt_regs *regs)
{
        long ret = 0;
[...]
        /* do the secure computing check first */
        secure_computing(regs->orig_ax);		<-- secomp!

        if (unlikely(test_thread_flag(TIF_SYSCALL_EMU)))
                ret = -1L;

        if ((ret || test_thread_flag(TIF_SYSCALL_TRACE)) &&
            tracehook_report_syscall_entry(regs))
                ret = -1L;

        if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
                trace_sys_enter(regs, regs->orig_ax);	<--here!
----

All syscalls issued by threads which has TIF_SYSCALL_TRACEPOINT
kick trace_sys_enter() tracepoint, and then the tracepoint calls
ftrace handler or perf handler.

And this tracepoint is not only for ftrace/perf, but also you
can use it directly via register_trace_sys_enter() (the tracepoint
can be shared among several handlers). If you just want to hook
the syscall entry, I recommend that instead of modifying ftrace/perf.
See kernel/trace/trace_syscalls.c, Documentation/trace/tracepoints.txt
and samples/tracepoints/ for details.

However, I think here is an ordering problem. As you can see, secomp
hook is done before these hooks, that might cause a problem because
tracehook_report_syscall_entry(), which is also done before tracepoint,
is used by ptrace().
This means that someone can hook into an unsafe syscall via debugger.

So, finally, I think you'd better expand secure_computing() hook, or
introduce more generic hook-point.

Thank you,

-- 
Masami HIRAMATSU
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com

  reply	other threads:[~2011-02-02 12:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-12 21:28 Eric Paris
2011-02-01 14:58 ` Eric Paris
2011-02-02 12:14   ` Masami Hiramatsu [this message]
2011-02-02 12:26     ` Ingo Molnar
2011-02-02 16:45       ` Eric Paris
2011-02-02 17:55         ` Ingo Molnar
2011-02-02 18:17           ` Steven Rostedt
2011-02-03 19:06         ` Frederic Weisbecker
2011-02-03 19:18           ` Frederic Weisbecker
2011-02-03 22:06           ` Stefan Fritsch
2011-02-03 23:10             ` Frederic Weisbecker
2011-02-04  1:50               ` Eric Paris
2011-02-04 14:31                 ` Peter Zijlstra
2011-02-04 16:29                   ` Eric Paris
2011-02-04 17:04                     ` Frederic Weisbecker
2011-02-05 11:51                       ` Stefan Fritsch
2011-02-07 12:26                         ` Peter Zijlstra
2011-02-04 16:36             ` Eric Paris
2011-02-05 11:42               ` Stefan Fritsch
2011-02-06 16:51                 ` Eric Paris

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=4D494AB1.1040508@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=2nddept-manager@sdl.hitachi.co.jp \
    --cc=agl@google.com \
    --cc=eparis@parisplace.org \
    --cc=eparis@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=jbaron@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@elte.hu \
    --cc=tzanussi@gmail.com \
    --subject='Re: Using ftrace/perf as a basis for generic seccomp' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).