linux-kernel - Re: [RFC][PATCH 0/4] ftrace: Use -mfentry when supported (this is for x86

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:	Fri, 18 Feb 2011 01:07:28 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Andi Kleen <andi@...stfloor.org>,
	2nddept-manager@....hitachi.co.jp
Subject: Re: [RFC][PATCH 0/4] ftrace: Use -mfentry when supported (this is
 for x86_64 right now)

(2011/02/18 0:46), Steven Rostedt wrote:
> On Fri, 2011-02-18 at 00:34 +0900, Masami Hiramatsu wrote:
>> (2011/02/17 22:18), Steven Rostedt wrote:
>>> On Thu, 2011-02-17 at 21:37 +0900, Masami Hiramatsu wrote:
>>>
>>>> Oops! with this change, current kprobes might not be able to probe
>>>> the entry of functions, because that is always reserved by ftrace!
>>>> I think we need to have some new interface for replacing each other
>>>> safely...
>>>
>>> Good point. I suspect that this wont be ready till .40 anyway. When I
>>> get a chance to work more an this, I'll also include patches where if
>>> -mfentry is activated kprobes will just hook to the mcount caller
>>> instead. Or ftrace itself :)
>>
>> Ah, that's a good idea! :) it could be done without -mfentry too.
>> But is that possible to modify just one mcount entry? I also worry
>> about the latency of enabling/disabling one entry.
> 
> I would have it go through the ftrace function tracing facility, which
> would handle which entry to enable/disable. It still does stopmachine.
> Is that an issue to enable/disable kprobes? The "fast" enable/disable
> could be done by the called function to just ignore the call.

I just thought that frequent stop-machine is not so good from the user's
POV. I agree that disabled probe ignoring the call is enough.
Maybe, it could be done with the similar mechanism of jump optimization.

> Also note, if there's other callbacks that are attached to the function
> being traced, no stop machine is enabled. The callbacks are just a list
> and as long as a function has an associated callback, no code
> modification needs to be done to add or remove other callbacks.

Right :)

>> BTW, without dynamic ftrace (no code modifying), I think we don't
>> need to reserve mcount code, because no one modifies it.
> 
> Correct. And even today, you can remove any kprobe code that checks for
> mcount without dynamic ftrace enabled. But I'm not sure if anyone
> enables the function tracer without dynamic ftrace, except for debugging
> in archs that do not support dynamic ftrace. As the overhead of this is
> quite high even when function tracer is disabled.

Indeed. Maybe that is only for that exception case, because it allows
us to put probe even on the mcount call.

Thank you,

-- 
Masami HIRAMATSU
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development 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/