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
next prev parent 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 Using ftrace/perf as a basis for generic seccomp 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 \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox