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 11:34:44 +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>
Subject: Re: live kernel upgrades (was: live kernel patching design)

* Ingo Molnar <mingo@...nel.org> wrote:

>   - implement live kernel upgrades by:
> 
>       - snapshotting all system state transparently

Note that this step can be sped up further in the end, 
because most of this work can be performed asynchronously 
and transparently prior to the live kernel upgrade step 
itself.

So if we split the snapshotting+parking preparatory step 
into two parts:

        - do opportunistic snapshotting of 
          sleeping/inactive user tasks while allowing 
          snapshotted tasks to continue to run

        - once that is completed, do snapshotting+parking 
          of all user tasks, even running ones

The first step is largely asynchronous, can be done with 
lower priority and does not park/stop any tasks on the 
system.

Only the second step counts as 'system stoppage time': and 
only those tasks have to be snapshotted again which 
executed any code since the first snapshotting run was 
performed.

Note that even this stoppage time can be reduced further: 
if a system is running critical services/users that need as 
little interruption as possible, they could be 
prioritized/ordered to be snapshotted/parked closest to the 
live kernel upgrade step.

>       - fast-rebooting into the new kernel image without 
>         shutting down and rebooting user-space, i.e. _much_ 
>         faster than a regular reboot.
> 
>       - restoring system state transparently within the new 
>         kernel image and resuming system workloads where 
>         they were left.
> 
> Even complex external state like TCP socket state and 
> graphics state can be preserved over an upgrade. As far 
> as the user is concerned, nothing happened but a brief 
> pause - and he's now running a v3.21 kernel, not v3.20.

So all this would allow 'live, rolling kernel upgrades' in 
the end.

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/