linux-kernel - Re: [kprobes/x86] a19b2e3d78: WARNING:at_kernel/locking/lockdep.c:#trace_hardirqs_off

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: <20171003101012.12cee3b5f7085ddbd0d63fb8@kernel.org>
Date:   Tue, 3 Oct 2017 10:10:12 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     kernel test robot <fengguang.wu@...el.com>,
        Ingo Molnar <mingo@...nel.org>,
        Alexei Starovoitov <ast@...com>,
        Alexei Starovoitov <ast@...nel.org>,
        Ananth N Mavinakayanahalli <ananth@...ux.vnet.ibm.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        "H. Peter Anvin" <hpa@...or.com>, tipbuild@...or.com, lkp@...org
Subject: Re: [kprobes/x86]  a19b2e3d78:
 WARNING:at_kernel/locking/lockdep.c:#trace_hardirqs_off_caller

On Mon, 2 Oct 2017 18:05:43 +0200
Peter Zijlstra <peterz@...radead.org> wrote:

> On Tue, Oct 03, 2017 at 12:46:05AM +0900, Masami Hiramatsu wrote:
> > On Mon, 2 Oct 2017 09:33:16 +0200
> > Peter Zijlstra <peterz@...radead.org> wrote:
> 
> > > > [   87.018115] Call Trace:
> > > > [   87.025046]  trace_hardirqs_off+0xd/0xf
> > > > [   87.034185]  setjmp_pre_handler+0x6c/0x95
> > > > [   87.043738]  kprobe_ftrace_handler+0xc3/0xf4
> > > 
> > > 
> > > So setjmp_pre_handler() does:
> > > 
> > > 	regs->flags &= ~X86_EFLAGS_IF;
> > > 	trace_hardirqs_off();
> > > 	regs->ip = (unsigned long)(jp->entry);
> > > 
> > > Which clears IF on the regs, but those will only take effect after an
> > > IRET, not instantly. This messes up he IRQ state tracing, which you're
> > > telling it will instantly disable IRQs.
> > 
> > Thanks for analyzing!
> > And right, since IRQ should be off while jump handler, it changes
> > regs->flags. (but ...why?)
> 
> Otherwise the IRET could re-enable interrupts?

Ah, I meant why IRQ should be disabled... It doesn't guarantee to
avoid nested kprobes (since another kprobe can be hit in jprobe
handler).

> > > A possible 'fix' would be to do local_irq_disable() in front of that,
> > > but I got pretty lost in that stuff so I can't say for sure if that
> > > makes sense or not.
> > 
> > I'm not sure how lockdep traces irq-disabling state, but it seems
> > that "enabling" irq state(trace_hardirqs_on()) is already missing
> > from kprobes.
> 
> If you could point me at where that is supposed to happen I can have a
> look at how that tracing works. I got lost in the code this morning.

The right place to decrement irq counter(trace_hardirqs_on()) should
be longjmp_break_handler(), which recovers flags register with other
registers from kcb->jprobe_saved_regs, and IRET recovers IF.
(maybe it doesn't count inc/dec correctly, isn't it?)

> > I'm considering to remove disabling-irq itself from jprobe.
> > (Frankly to say, I would like to remove jprobe itself...)
> 
> That would obviously also solve all problems :-)

Yeah, for long term it needs to be removed :)

Thank you,

-- 
Masami Hiramatsu <mhiramat@...nel.org>