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]

Message-ID: <20200310170536.w4p5r2fnsyaorys5@holly.lan>
Date:   Tue, 10 Mar 2020 17:05:36 +0000
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Steven Rostedt <rostedt@...dmis.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Joel Fernandes <joel@...lfernandes.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Jason Wessel <jason.wessel@...driver.com>
Subject: Re: Instrumentation and RCU

On Tue, Mar 10, 2020 at 05:09:51PM +0900, Masami Hiramatsu wrote:
> Hi,
> 
> On Mon, 09 Mar 2020 19:59:18 +0100
> Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> > >> #2) Breakpoint utilization
> > >> 
> > >>     As recent findings have shown, breakpoint utilization needs to be
> > >>     extremly careful about not creating infinite breakpoint recursions.
> > >> 
> > >>     I think that's pretty much obvious, but falls into the overall
> > >>     question of how to protect callchains.
> > >
> > > This is rather unique, and I agree that its best to at least get to a point
> > > where we limit the tracing within breakpoint code. I'm fine with making
> > > rcu_nmi_exit() nokprobe too.
> > 
> > Yes, the break point stuff is unique, but it has nicely demonstrated how
> > much of the code is affected by it.
> 
> I see. I had followed the callchain several times, and always found new function.
> So I agree with the off-limit section idea. That is a kind of entry code section
> but more generic one. It is natural to split such sensitive code in different
> place.
> 
> BTW, what about kdb stuffs? (+Cc Jason)

There is some double breakpoint detection code but IIRC this merely
retrospectively warns the user that they have their hurt their system...
and whether the system would run long enough to reach that logic is
relatively unlikely.

For both kdb and kgdb, the main "defence" is the use case. Neither kdb
or kgdb faces the userspace (except via a SysRq, which can be disabled)
and triggering either already implies the user is not especially
concerned about things like availability guarantees since they are happy
for everything running on the system to be halted indefinitely.

Additionally breakpoints in kgdb/kdb are not wildcarded so there are no
need to worry about a user selecting a bad pattern! Setting a breakpoint
with kgdb/kdb needs a user (who is assumed to have kernel knowledge) to
have explicitly chose to study the dynamic behaviour of that particular
bit of code.

I'm not saying kgdb/kdb would not benefit from additional safety
barriers (it would), simply that the problem is less acute.

Daniel.