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:   Mon, 8 May 2017 15:43:33 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Petr Mladek <pmladek@...e.com>, Jessica Yu <jeyu@...hat.com>,
        Jiri Kosina <jikos@...nel.org>,
        Miroslav Benes <mbenes@...e.cz>, live-patching@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is
 broken in RCU code

On Mon, May 08, 2017 at 01:15:58PM -0700, Paul E. McKenney wrote:
> On Mon, May 08, 2017 at 02:47:29PM -0500, Josh Poimboeuf wrote:
> > On Mon, May 08, 2017 at 03:13:22PM -0400, Steven Rostedt wrote:
> 
> [ . . . ]
> 
> > > If rcu is not watching, calling rcu_enter_irq() will have it watch
> > > again. Even in NMI context I believe.
> > 
> > What if you get an NMI while running in rcu_dynticks_eqs_enter() before
> > it increments rdtp->dynticks?  Will rcu_enter_irq() still work from the
>                                       rcu_irq_enter()
> > NMI?
> 
> The rcu_nmi_enter() function willl notice that RCU is not watching, and
> will therefore atomically increment RCU's dynticks-idle counter, which
> will be atomically incremented again upon return.  Since the bottom bit
> of this counter controls whether or not RCU is watching, RCU will be
> watching during the NMI, will stop watching upon return from the NMI,
> which restores state so as to allow rcu_irq_enter() to cause RCU to once
> again watch.  (NMI algorithm due to Andy Lutomirski.)
> 
> > I'm just trying to understand what are the cases where rcu_enter_irq()
> > *doesn't* work from an ftrace handler.
> 
> It doesn't work from an NMI handler.  Aside from possible architecture
> specific special cases, it should work everywhere else.

Ok, so just to clarify.  Is there a bug in the ftrace stack tracer in
the following situation?

1. RCU isn't watching
2. An NMI hits
3. ist_enter() calls into the ftrace stack tracer, before
   rcu_nmi_enter() is called, so RCU isn't watching yet
4. The ftrace stack tracer calls rcu_irq_enter(), which has no effect,
   so RCU still isn't watching
5. Hilarity ensues in the ftrace stack tracer

-- 
Josh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ