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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 10 Mar 2020 11:31:51 -0400 (EDT)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        rostedt <rostedt@...dmis.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 Mar 10, 2020, at 7:43 AM, Thomas Gleixner tglx@...utronix.de wrote:

[...]
> 
> That's why we want the sections and the annotation. If something calls
> out of a noinstr section into a regular text section and the call is not
> annotated at the call site, then objtool can complain and tell you. What
> Peter and I came up with looks like this:
> 
> noinstr foo()
>	do_protected(); <- Safe because in the noinstr section
> 
>	instr_begin();	<- Marks the begin of a safe region, ignored
>        		   by objtool
> 
>        do_stuff();     <- All good
> 
>        instr_end();    <- End of the safe region. objtool starts
>			   looking again
> 
>        do_other_stuff();  <- Unsafe because do_other_stuff() is
>        		      not protected
> and:
> 
> noinstr do_protected()
>        bar();		<- objtool will complain here
> 
> See?

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.

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com