linux-kernel - Re: [PATCH ftrace/core v6 4/5] kprobes: Set IPMODIFY flag only if the probe can change regs->ip

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:	Tue, 24 Feb 2015 16:38:18 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Petr Mladek <pmladek@...e.cz>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Jiri Kosina <jkosina@...e.cz>,
	Seth Jennings <sjenning@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Vojtech Pavlik <vojtech@...e.cz>,
	Namhyung Kim <namhyung@...nel.org>,
	Miroslav Benes <mbenes@...e.cz>, Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH ftrace/core v6 4/5] kprobes: Set IPMODIFY flag only if
 the probe can change regs->ip

Hi Petr,

Sorry I missed this mail.

(2015/01/27 1:14), Petr Mladek wrote:> On Fri 2014-11-21 05:25:30, Masami Hiramatsu wrote:
>> Set FTRACE_OPS_FL_IPMODIFY flag only for the probes which can change
>> regs->ip, which has kprobe->break_handler.
>> Currently we can not put jprobe and another ftrace handler which
>> changes regs->ip on the same function because all kprobes have
>> FTRACE_OPS_FL_IPMODIFY flag. This removes FTRACE_OPS_FL_IPMODIFY
>> flag from kprobes and only when the user uses jprobe (or the
>> kprobe.break_handler != NULL) we add additinal ftrace_ops with
>> FTRACE_OPS_FL_IPMODIFY on target function.
>
> Please, what are the plans with this patch?

Well, I'll revise this for newer kernel.

>
> I have checked the interference between Kprobes and LivePatching and
> here is my observation:
>
> 1. Jprobe and LivePatch must be in a hard conflict. They both need
>    to change IP and continue another way after ftrace ops finishes.
>
>    BTW: I wonder a bit why Jprobe handler could not be called directly
>    from kprobe_ftrace_handler(). I guess that it is because we want
>    to call the kprobe handler in a sane context: preemption and IRQs
>    enabled, be able to use traced functions.

Right, Jprobe is just a different interface of kprobe handler. It must be
called from kprobes.
However, I think this is not so hard in practice, since we already have
perf-probe which allows us to find which register or stack is assigned to
which function parameter. That was the main reason why jprobe is introduced.
But now, we have perf-probe or systemtap, we don't(or less) need the hack like
jprobe anymore.


> 2. Normal Kprobe for the original function is ignored if the function
>    is patched.
>
>    I am working on a code that will print warning in both
>    cases. First, when we add a patch and the function has
>    a Kprobe registered. Second, the function is patched and
>    we want to add Kprobe for the original version.

Thanks! Maybe we can add "Ignored" flag for those kprobes so that users
can check it is working or not via debugfs.

>    I want to make it generic and make it dependent on the
>    IPMODIFY flag. IMHO, it just could be a handshake between
>    kprobe and ftrace code. I am still trying to understand
>    the needed parts of the code ;-)

BTW, the kprobes on function entry (iow, ftrace-based kprobes) should
not be ignored. Even if we patches a function-body, the entrance
address should be same.


> 3. Kretprobe could live with a patch without a problem!
>
>    The Kretprobe entry handler is called directly in
>    kprobe_ftrace_handler() and does not change IP.
>    On the other hand the LivePatch ftrace handler does
>    not modify the return address because the return address
>    is the same for the original and the patched function.

Right.

>
>    Or did I miss something?
>
>    This is where this patch might be useful. The other patches
>    from this patch set are already in Linus' tree and I cannot
>    find any information about this one.

Well, thank you for picking it up!


>
>    I could try to solve remaining problems if there are any.
>

Thank you,


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research 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/