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]

Message-ID: <20150224091621.GA19976@gmail.com>
Date:	Tue, 24 Feb 2015 10:16:21 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Arjan van de Ven <arjanvandeven@...il.com>
Cc:	Dave Airlie <airlied@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Vojtech Pavlik <vojtech@...e.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Seth Jennings <sjenning@...hat.com>,
	LKML <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)

* Arjan van de Ven <arjanvandeven@...il.com> wrote:

> I think 10 seconds is Ingo being a bit exaggerating, 
> since you can boot a full system in a lot less time than 
> that, and more so if you know more about the system (e.g. 
> don't need to spin down and then discover and spin up 
> disks). If you're talking about inside a VM it's even 
> more extreme than that.

Correct, I mentioned 10 seconds latency to be on the safe 
side - but in general I suspect it can be reduced to below 
1 second, which should be enough for everyone but the most 
specialized cases: even specialized HA servers will update 
their systems in low activity maintenance windows.

and we don't design the Linux kernel for weird, extreme 
cases, we design for the common, sane case that has the 
broadest appeal, and we hope that the feature garners 
enough interest to be maintainable.

This is not a problem in general: the weird case can take 
care of itself just fine - 'specialized and weird' usually 
means there's enough money to throw at special hardware and 
human solutions or it goes extinct quickly ...

Thanks,

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