linux-kernel - Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching

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: <20140516145533.4ef7bc22@gandalf.local.home>
Date:	Fri, 16 May 2014 14:55:33 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Ingo Molnar <mingo@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Seth Jennings <sjenning@...hat.com>,
	Ingo Molnar <mingo@...hat.com>, Jiri Slaby <jslaby@...e.cz>,
	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching

On Fri, 16 May 2014 18:27:27 +0200 (CEST)
Jiri Kosina <jkosina@...e.cz> wrote:

> > ftrace did the stop_machine (and still does for some archs), and slowly
> > moved to a more efficient method. kpatch/kgraft should follow suit.
> 
> I don't really agree here.
> 
> I actually believe that "lazy" switching kgraft is doing provides a little 
> bit more in the sense of consistency than stop_machine()-based aproach.
> 
> Consider this scenario:
> 
> 	void foo()
> 	{
> 		for (i=0; i<10000; i++) {
> 			bar(i);
> 			something_else(i);
> 		}
> 	}
> 
> Let's say you want to live-patch bar(). With stop_machine()-based aproach, 
> you can easily end-up with old bar() and new bar() being called in two 
> consecutive iterations before the loop is even exited, right? (especially 
> on preemptible kernel, or if something_else() goes to sleep).

And bar() should still do the same result. Otherwise you would think
that foo should change too.

> 
> With lazy-switching implemented in kgraft, this can never happen.
> 
> So I'd like to ask for a little bit more explanation why you think the 
> stop_machine()-based patching provides more sanity/consistency assurance 
> than the lazy switching we're doing.

Here's what I'm more concerned with. With "lazy" switching you can have
two tasks running two different versions of bar(). What happens if the
locking of data within bar changes? Say the data was protected
incorrectly with mutex(X) and you now need to protect it with mutex(Y).

With stop machine, you can make sure everyone is out of bar() and all
tasks will use the same mutex to access the data. But with a lazy
approach, one task can be protecting the data with mutex(X) and the
other with mutex(Y) causing both tasks to be accessing the data at the
same time.

*That* is what I'm more concerned about.

I believe there are more issues with running the two different versions
of the same function at the same time than there are with iterations of
two different versions of the call. One would expect that the results
should stay the same and if not, then the callers would need to be
changed too.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/