linux-kernel - Re: live kernel upgrades (was: live kernel patching design)

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:	Sun, 22 Feb 2015 20:13:28 +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>,
	Arjan van de Ven <arjan@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Borislav Petkov <bp@...en8.de>, live-patching@...r.kernel.org
Subject: Re: live kernel upgrades (was: live kernel patching design)

[ added live-patching@ ML as well, in consistency with Josh ]

On Sun, 22 Feb 2015, Ingo Molnar wrote:

> It's all still tons of work to pull off a 'live kernel upgrade' on 
> native hardware, but IMHO it's tons of very useful work that helps a 
> dozen non-competing projects, literally.

Yes, I agree, it might be nice-to-have feature. The only issue with that 
is that it's solving a completely different problem than live patching.

Guys working on criu have made quite a few steps in that direction of 
already course; modulo bugs and current implementation limitations, you 
should be able to checkpoint your userspace, kexec to a new kernel, and 
restart your userspace.

But if you ask the folks who are hungry for live bug patching, they 
wouldn't care.

You mentioned "10 seconds", that's more or less equal to infinity to them. 
And frankly, even "10 seconds" is something we can't really guarantee. We 
could optimize the kernel the craziest way we can, but hardware takes its 
time to reinitialize. And in most cases, you'd really need to reinitalize 
it; I don't see a way how you could safely suspend it somehow in the old 
kernel and resume it in a new one, because the driver suspending the 
device might be completely different than the driver resuming the device. 
How are you able to provide hard guarantees that this is going to work?

So all in all, if you ask me -- yes, live kernel upgrades from v3.20 to 
v3.21, pretty cool feature. Is it related to the problem we are after with 
live bug patching? I very much don't think so.

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/