linux-kernel - Re: [BUGFIX PATCH] kprobes/x86: Remove IRQ disabling from jprobe handlers

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: <20171005075704.2wv3vcg35s4g5jhq@gmail.com>
Date:   Thu, 5 Oct 2017 09:57:04 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     mingo@...hat.com, x86@...nel.org,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Ananth N Mavinakayanahalli <ananth@...ux.vnet.ibm.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        "Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Alexei Starovoitov <ast@...com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [BUGFIX PATCH] kprobes/x86: Remove IRQ disabling from jprobe
 handlers


* Masami Hiramatsu <mhiramat@...nel.org> wrote:

> On Wed, 4 Oct 2017 12:41:01 +0200
> Ingo Molnar <mingo@...nel.org> wrote:
> 
> > 
> > * Masami Hiramatsu <mhiramat@...nel.org> wrote:
> > 
> > > Hmm, actually we can not disable jprobe, that has no separate Kconfig.
> > > So we need to introduce new kconfig for that.
> > > 
> > > And, there are several network protocols using jprobe to trace events.
> > > (e.g. NET_DCCPPROBE and NET_TCPPROBE)
> > > I think they need to migrate to trace-event at first.
> > > 
> > > So, how about below idea?
> > > 
> > > 1. Introduce CONFIG_JPROBE_API which only separate jprobe general parts
> > >      (no arch dependent code involves) and make it default n.
> > > 2. Mark break_handler and jprobe APIs deprecated so that no new user comes up.
> > > 3. migrate in-kernel jprobe user to trace-event or ftrace.
> > >    (may take some time)
> > 
> > So my suggestion would be to just return from register_jprobe() and don't register 
> > anything.
> 
> with CONFIG_JPROBE_API=n, is that right?

No, unconditionally off with a WARN_ON_ONCE() warning in the registry function and 
the deactivation of all in-kernel uses (such as self-tests).

The point is to make people that _truly_ rely on it complain - not just make them 
silently turn on a Kconfig option ...

> > Yes, there are usecases of jprobes in the kernel, but they all look 
> > pretty ancient and unused.
> 
> Hmm, in that case, should we also remove those users? If we disable such way
> those features are just useless.

My hypothesis is that those features are not used (hence useless), but we should 
first test whether there's any reliance before we remove code.

Thanks,

	Ingo