linux-kernel - Re: [RFC PATCH -tip 8/9] kprobes: introduce ftrace based optiomization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 May 2012 16:56:25 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	ananth@...ibm.com
Cc:	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	yrl.pp-manager.tt@...achi.com
Subject: Re: [RFC PATCH -tip  8/9] kprobes: introduce ftrace based optiomization

(2012/05/30 16:22), Ananth N Mavinakayanahalli wrote:
> On Tue, May 29, 2012 at 09:49:45PM +0900, Masami Hiramatsu wrote:
>> Introduce function trace based kprobes optimization.
>>
>> With using ftrace optimization, kprobes on the mcount calling
>> address, use ftrace's mcount call instead of breakpoint.
>> Farthermore, this optimization works with preemptive kernel
>> not like as current jump-based optimization. Of cource,
>> this feature is limited only if the probe on mcount call.
> 
> The above paragraph doesn't parse correctly for me. Do you mean to say
> if the probe is on the mcount calling address, use the jump based
> approach instead of the breakpoint one? Could you please rephrase?

Right, but not use current jump-base one, but use function
tracer handler directly.

So, ftrace-based optimization will be done on the kprobe at
the mcount calling address, which has been replaced with a
5 byte NOP at the build-time.
The ftrace-based optimization uses function-tracer handler
(kernel/trace/ftrace.c) instead of int3 breakpoint trapping.

The probing behavior is like below

1. hit mcount calling address
2. call ftrace_caller
  -> 3. save all registers
     4. call ftrace's handler (kprobe_ftrace_handler)
       -> 5. set up current kprobe
          6. call kprobe handler
       <- 7. return
     8. restore registers
  <- 9. return
10. continue to run

>> +static void __kprobes kprobe_ftrace_init(void)
>> +{
>> +	int ret;
>> +
>> +	ret = register_ftrace_function(&kprobe_ftrace_ops);
>> +	WARN(ret < 0, "Failed to init kprobe-ftrace (%d)\n", ret);
>> +
>> +	kprobe_ftrace_enabled = 1;
> 
> Hmm.. is this right? kprobe_ftrace_enabled is 1 even if the init failed.

Oops, that should be a bug! thanks!


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/