linux-kernel - Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code

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:   Thu, 11 May 2017 14:50:00 +0200 (CEST)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Steven Rostedt <rostedt@...dmis.org>
cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Petr Mladek <pmladek@...e.com>, Jessica Yu <jeyu@...hat.com>,
        Jiri Kosina <jikos@...nel.org>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        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, 8 May 2017, Steven Rostedt wrote:

> On Mon, 8 May 2017 14:47:29 -0500
> Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> 
> > > Although you should have:
> > > 
> > > 	if (WARN_ONCE(!rcu_is_watching,
> > > 			"Livepatch ..."))
> > > 		return;
> > > 
> > > or something to not cause any damage.  
> > 
> > My understanding is that returning would be more dangerous than
> > continuing here.
> > 
> > By continuing to run, there's only a small chance that it will get stale
> > data, which would break the consistency model by executing an old
> > version of the function and possibly crashing the system.
> > 
> > On the other hand, returning would unconditionally break the consistency
> > model by *always* executing an old version of the function.  So that
> > greatly increases the risk of a crash.
> 
> I was being oversimplified by saying 'return', perhaps go into a
> critical mode that can try again, or perhaps even back out the patch.
> As in a transaction style. Yes, this will need to be thought through to
> know how to get out. My comment wasn't meant to be simple.

Well, live patching is in fact transactional. To some extent. If we fail 
during ftrace registration we abort the action gracefully. After the 
registration it gets more interesting because the whole system is 
"asynchronously" migrated to a final patched state. Even during this stage 
we can reverse the process (klp_reverse_transition()), but it was not easy 
to get it right...

... and to implement or start this logic from the handler sends shivers 
down my spine.

We still can try.

Thanks,
Miroslav