linux-kernel - Re: [PATCH tip/master v3] kprobes: extable: Identify kprobes' insn-slots as kernel text area

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:   Wed, 4 Jan 2017 09:21:45 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        linux-kernel@...r.kernel.org,
        Ananth N Mavinakayanahalli <ananth@...ux.vnet.ibm.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        Andrey Konovalov <andreyknvl@...gle.com>
Subject: Re: [PATCH tip/master v3] kprobes: extable: Identify kprobes'
 insn-slots as kernel text area

On Tue, 3 Jan 2017 11:54:02 +0100
Peter Zijlstra <peterz@...radead.org> wrote:

> How many entries should one expect on that list? I spend quite a bit of
> time reducing the cost of is_module_text_address() a while back and see
> that both ftrace (which actually needs this to be fast) and now
> kprobes have linear list walks in here.
> 
> I'm assuming the ftrace thing to be mostly empty, since I never saw it
> on my benchmarks back then, but it is something Steve should look at I
> suppose.

Yeah, that do_for_each_ftrace_op() loop iterates all the users that
have connected to function tracing. Which in your case is probably at
most 2 (one for ftrace and one for perf). You could get more by
creating instances and enabling function tracing there too. Oh, and the
stack tracer could add its own.

Hmm, with the addition of live kernel patching, this list could get
larger. As you can have one per updated function. But heh, that's just
part of the overhead for live patching ;-)

-- Steve