linux-kernel - Re: [RFC PATCH 6/9] livepatch: create per-task consistency model

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, 12 Feb 2015 14:16:07 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Josh Poimboeuf <jpoimboe@...hat.com>,
	Ingo Molnar <mingo@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
	Seth Jennings <sjenning@...hat.com>,
	Vojtech Pavlik <vojtech@...e.cz>
Subject: Re: [RFC PATCH 6/9] livepatch: create per-task consistency model

On Thu, 12 Feb 2015, Peter Zijlstra wrote:

> > The short answer is: I need a way to ensure that a task isn't sleeping
> > on any of the functions we're trying to patch.  If it's not, then I can
> > switch the task over to start using new versions of functions.
> > 
> > Obviously, there are many more details than that.  If you have specific
> > questions I can try to answer them.
> 
> How can one task run new and another task old functions? Once you patch
> any indirect function pointer any task will see the new call.

Patched functions are redirected through ftrace trampoline, and decision 
is being made there which function (old or new) to redirect to.

Function calls through pointer always go first to the original function, 
and get redirected from its __fentry__ site.

Once the system is in fully patched state, the overhead of the trampoline 
is reduced (no expensive decision-making to be made there, etc) to 
minimum.

Sure, you will never be on a 100% of performance of the unpatched kernel 
for redirected functions, the indirect call through the trampoline will 
always be there (although ftrace with dynamic trampolines is really 
minimizing this penalty to few extra instructions, one extra call and one 
extra ret being the expensive ones).

> And what's wrong with using known good spots like the freezer?

It has undefined semantics when it comes to what you want to achieve here.

Say for example you have a kernel thread which does something like

while (some_condition) {
	ret = foo();
	...
	try_to_freeze();
	...
}

and you have a livepatch patching foo() and changing its return value 
semantics. Then freezer doesn't really help.

-- 
Jiri Kosina
SUSE Labs
--
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/