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:	Tue, 24 Feb 2015 11:53:28 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Jiri Kosina <jkosina@...e.cz>
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)

* Jiri Kosina <jkosina@...e.cz> wrote:

> [...] 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; [...]

If we want to reinitialize a device, most of the longer 
initialization latencies during bootup these days involve 
things like: 'poke hardware, see if there's any response'. 
Those are mostly going away quickly with modern, 
well-enumerated hardware interfaces.

Just try a modprobe of a random hardware driver - most 
initialization sequences are very fast. (That's how people 
are able to do cold bootups in less than 1 second.)

In theory this could also be optimized: we could avoid the 
reinitialization step through an upgrade via relatively 
simple means, for example if drivers define their own 
version and the new kernel's driver checks whether the 
previous state is from a compatible driver. Then the new 
driver could do a shorter initialization sequence.

But I'd only do it only in special cases, where for some 
reason the initialization sequence takes longer time and it 
makes sense to share hardware discovery information between 
two versions of the driver. I'm not convinced such a 
mechanism is necessary in the general case.

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/