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

[Masami Hiramatsu]

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

> On Thu, Oct 5, 2017 at 4:13 PM, Masami Hiramatsu <mhiramat@xxxxxxxxxx> 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@xxxxxxxxxx>