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:   Thu, 5 Oct 2017 16:35:22 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Masami Hiramatsu <mhiramat@...nel.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, 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):

static unsigned int jp_do_irq(unsigned int irq)
{
        lkdtm_handler();
        jprobe_return();
        return 0;
}

What's the right way to migrate away from jprobe for lkdtm?

Thanks!

-Kees

-- 
Kees Cook
Pixel Security