linux-kernel - Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

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, 6 Oct 2017 09:32:52 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Ananth N Mavinakayanahalli <ananth@...ux.vnet.ibm.com>,
        "Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        "H . Peter Anvin" <hpa@...or.com>,
        Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
        "David S . Miller" <davem@...emloft.net>,
        Ian McDonald <ian.mcdonald@...di.co.nz>,
        Vlad Yasevich <vyasevich@...il.com>,
        Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs

On Thu, 5 Oct 2017 16:35:22 -0700
Kees Cook <keescook@...omium.org> wrote:

> On Thu, Oct 5, 2017 at 4:13 PM, Masami Hiramatsu <mhiramat@...nel.org> wrote:
> > Hi,
> >
> > This series abolishes jprobe APIs and remove or disable related
> > code. This is a preparation of removing all jprobe code (including
> > kprobe's break_handler.)
> > I'm not so sure how many jprobe users still exists, but
> > please migrate your tool to trace-event or perf-probe.
> >
> > As we discussed this thread ( https://lkml.org/lkml/2017/10/2/386 ),
> > we decided to remove jprobe.
> >
> > Nowadays ftrace and other tracing features are enough matured
> > to replace jprobe use-cases. Users can safely use ftrace and
> > perf probe etc. for their use cases. So we have better way.
> > IOW, jprobe finished its task.
> >
> > People who still use jprobe, must migrate to other tracing features.
> > Please consider to migrate your tool to following options.
> >
> > - Use trace-event to trace target function with arguments
> >   trace-event is a low-overhead (and almost no visible overhead if it
> >   is off) statically defined event interface. You can define new events
> >   and trace it via ftrace or any other tracing tools.
> >   See following urls,
> >   - https://lwn.net/Articles/379903/
> >   - https://lwn.net/Articles/381064/
> >   - https://lwn.net/Articles/383362/
> 
> It seems this method requires setting up the target trace ahead of time?
> 
> > - Use ftrace dynamic events (kprobe event) with perf-probe
> >   If you build your kernel with debug info (CONFIG_DEBUG_INFO), you can
> >   find which register/stack is assigned to which local variable or arguments
> >   by using perf-probe and set up new event to trace it.
> >   See following documents,
> >   - Documentation/trace/kprobetrace.txt
> >   - Documentation/trace/events.txt
> >   - tools/perf/Documentation/perf-probe.txt
> 
> These seem to be more about setting up probes from userspace.
> 
> > As far as I can see, tcp probe, dccp probe, sctp probe and lkdtm
> > are using jprobe to probe function. Please consider to migrate.
> 
> I'm happy to do so, but I'm quite unfamiliar with how to do this (I
> didn't write lkdtm's jprobe code originally). lkdtm just wants to hook
> function entry and call it's own function before.
> 
> It uses struct jprobe like this:
> 
>                 .jprobe = {                                     \
>                         .kp.symbol_name = _symbol,              \
>                         .entry = (kprobe_opcode_t *)_entry,     \
>                 },                                              \
> 
> and defines a bunch of handlers like this for the _symbol and _entry pairs:
> 
>                    "do_IRQ",                    jp_do_irq),
> ...
>                    "tasklet_action",            jp_tasklet_action),
> 
> where all the handlers look exactly the same (and don't care about arguments):

If so, you can just change it to kprobes instead of jprobe.
e.g.

	.kprobe = {
		.symbol_name = _symbol,
		.pre_handler = _entry,
	}

and 
	"do_IRQ",	kp_pre_handler),
...
	"tasklet_action",	kp_pre_handler),

both kp_do_irq and kp_tasklet_action has same signature, so you can
use same function like 

static unsigned int kp_pre_handler(struct kprobe *kp, struct pt_regs *regs)
{
        lkdtm_handler();
        return 0;
}

I think using ftrace gives you lower latency, but you need to depend on
CONFIG_FUNCTION_TRACER instead of CONFIG_KPROBES.

Anyway, please choose either one of those :)

Thank you,

-- 
Masami Hiramatsu <mhiramat@...nel.org>