linux-kernel - Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching

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: <20140506073228.GA26271@gmail.com>
Date:	Tue, 6 May 2014 09:32:28 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	David Lang <david@...g.hm>, Josh Poimboeuf <jpoimboe@...hat.com>,
	Seth Jennings <sjenning@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>, Jiri Slaby <jslaby@...e.cz>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching


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

> On Mon, 5 May 2014, David Lang wrote:
> 
> > how would you know that all instances of the datastructure in memory 
> > have= been touched? just because all tasks have run and are outside the 
> > function in question doesn't tell you data structures have been 
> > converted. You have n= o way of knowing when (or if) the next call to 
> > the modified function will take place on any potential in-memory 
> > structure.
> 
> The problem you are trying to avoid here is functions expecting to read 
> "v2" format of the data from memory, while there are still tasks that are 
> unpredictably writing "v1" format of the data to the memory.
> 
> There are several ways to attack this problem:
> 
> - stop the whole system, convert all the existing data structures to new 
>   format (which might potentially be non-trivial, mostly because you 
>   have to *know* where all the data structures have been allocated), apply 
>   patch, resume operation [ksplice, probably kpatch in future]
> - restrict the data format to be backwards compatible [to be done 
>   manually during patch creation, currently what kGraft needs to do in 
>   such case]
> - have a proxy code which can read both "v1" and "v2" formats, and writes 
>   back in the same format it has seen the data structure on input
> - once all the *code* has been converted, it still has to understand "v1" 
>   and "v2", but it can now start writing out "v2" format only [possible 
>   with kGraft, not implemented in automated fashion]
> 
> Ideas are of course more than welcome.

So what I'm curious about, what is the actual 'in the field' distro 
experience, about the type of live-patches that get pushed with 
urgency?

My guess would be that the overwhelming majority of live-patches don't 
change data structures - and hence the right initial model would be to 
ensure (via tooling, and via review) that 'v1' and 'v2' data is 
exactly the same.

The most abstract way to 'live patch' a kernel is to do a checkpoint 
save on all application state, to reboot the kernel, boot into the 
patched kernel and then restore all application state seemlessly.

i.e. the CR effort that has been going on for years, to save/restore 
all state that is exposed through a kernel ABI. That allows a complete 
kernel to be switched out, without affecting applications.

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/