linux-kernel - Re: live patching design (was: Re: [PATCH 1/3] sched: add sched_task

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: <alpine.LNX.2.00.1502212025450.2357@pobox.suse.cz>
Date:	Sat, 21 Feb 2015 20:31:48 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Ingo Molnar <mingo@...nel.org>
cc:	Vojtech Pavlik <vojtech@...e.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Seth Jennings <sjenning@...hat.com>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: live patching design (was: Re: [PATCH 1/3] sched: add
 sched_task_call())

On Sat, 21 Feb 2015, Ingo Molnar wrote:

> > But admittedly, if we reserve a special sort-of signal 
> > for making the tasks pass through a safe checkpoint (and 
> > make them queue there (your solution) or make them just 
> > pass through it and continue (current kGraft)), it might 
> > reduce the time this effort needs considerably.
> 
> Well, I think the 'simple' method has another advantage: it can only 
> work if all those problems (kthreads, parking machinery) are solved, 
> because the patching will occur only everything is quiescent.
> 
> So no shortcuts are allowed, by design. It starts from a fundamentally 
> safe, robust base, while all the other approaches I've seen were 
> developed in a 'lets get the patching to work, then iteratively try to 
> make it safer' which really puts the cart before the horse.
> 
> So to put it more bluntly: I don't subscribe to the whole 'consistency 
> model' nonsense: that's just crazy talk IMHO.
> 
> Make it fundamentally safe from the very beginning, the 'simple method' 
> I suggested _won't live patch the kernel_ if the mechanism has a bug and 
> some kthread or task does not park. See the difference?

I see the difference, but I am afraid you are simplifying the situation a 
litle bit too much. 

There will always be properties of patches that will make them 
unapplicable in a "live patching" way by design. Think of data structure 
layout changes (*).

Or think of kernel that has some 3rd party vendor module loaded, and this 
module spawning a ktrehad that is not capable of parking itself.

Or think of patching __notrace__ functions.

Etc.

So it's not black and white, it's really a rather philosophical question 
where to draw the line (and make sure that everyone is aware of where the 
line is and what it means).
This is exactly why we came up with consistency models -- it allows you to 
draw the line at well-defined places.

(*) there are some rather crazy ideas how to make this work, but the price 
    you pay is basically always unacceptable slowdown

Thanks,

-- 
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/