linux-kernel - Re: Instrumentation and RCU

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200310114657.099122fd@gandalf.local.home>
Date:   Tue, 10 Mar 2020 11:46:57 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Alexei Starovoitov <ast@...nel.org>,
        paulmck <paulmck@...nel.org>,
        "Joel Fernandes, Google" <joel@...lfernandes.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Jason Wessel <jason.wessel@...driver.com>
Subject: Re: Instrumentation and RCU

On Tue, 10 Mar 2020 11:31:51 -0400 (EDT)
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:

> I think there are two distinct problems we are trying to solve here,
> and it would be good to spell them out to see which pieces of technical
> solution apply to which.
> 
> Problem #1) Tracer invoked from partially initialized kernel context
> 
>   - Moving the early/late entry/exit points into sections invisible from
>     instrumentation seems to make tons of sense for this.
> 
> Problem #2) Tracer recursion
> 
>   - I'm much less convinced that hiding entry points from instrumentation
>     works for this. As an example, with the isntr_begin/end() approach you
>     propose above, as soon as you have a tracer recursing into itself because
>     something below do_stuff() has been instrumented, having hidden the entry
>     point did not help at all.
> 
> So I would be tempted to use the "hide entry/exit points" with explicit
> instr begin/end annotation to solve Problem #1, but I'm still thinking there
> is value in the per recursion context "in_tracing" flag to prevent tracer
> recursion.

The only recursion issue that I've seen discussed is breakpoints. And
that's outside of the tracer infrastructure. Basically, if someone added a
breakpoint for a kprobe on something that gets called in the int3 code
before kprobes is called we have (let's say rcu_nmi_enter()):


 rcu_nmi_enter();
  <int3>
     do_int3() {
        rcu_nmi_enter();
          <int3>
             do_int3();
                [..]

Where would a "in_tracer" flag help here? Perhaps a "in_breakpoint" could?

-- Steve