linux-kernel - Re: [PATCH] livepatch: Add some basic LivePatch documentation

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] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.00.1603151256480.20252@pobox.suse.cz>
Date:	Tue, 15 Mar 2016 13:23:53 +0100 (CET)
From:	Miroslav Benes <mbenes@...e.cz>
To:	Jiri Kosina <jikos@...nel.org>
cc:	Petr Mladek <pmladek@...e.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Jessica Yu <jeyu@...hat.com>,
	Vojtech Pavlik <vojtech@...e.com>,
	live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	linuxppc-dev@...abs.org, Balbir Singh <bsingharora@...il.com>,
	Torsten Duwe <duwe@...e.de>,
	Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH] livepatch: Add some basic LivePatch documentation

On Thu, 10 Mar 2016, Jiri Kosina wrote:

> On Wed, 9 Mar 2016, Petr Mladek wrote:
> 
> > LivePatch framework deserves some documentation, definitely.
> > This is an attempt to provide some basic info. I hope that
> > it will be useful for both LivePatch producers and also
> > potential developers of the framework itself.
> 
> Thanks for starting the efforts; this is really needed if we want the 
> infrastructure to be used also by someone else than its developers :)

Indeed. Great job, Petr.

> [ ... snip ... ]
> > +7. Limitations
> > +==============
> 
> Miroslav Benes, who is working on creating the actual patches we are 
> shipping for our kernels, should already have a decent cheat-sheet 
> regarding things that the patch author should be extra careful when 
> creating a patch (inlining and other gcc optimizations such as isra, 
> functions that use switch_to(), percpu, ...).

Yes, my cheat-sheet is pretty long as of now, but the things there 
are mainly connected with the "userspace" part and they are not really 
limitations of current kernel implementation. Some of those are solvable 
with relocations and some depend on the patch development process 
(inlining, gcc optimizations and so on). I think it would be great to 
discuss it at Plumbers miniconference. It really depends on a future 
userspace tool which is on the list as well

> I am not really sure whether these should go to limitations, or maybe 
> they'd better be placed into a separate chapter, but I'd really like to 
> see it included.

Apart the limitations Petr has already described there are two more. And 
both quite serious to mention. First, we cannot patch and handle data 
structures. Sometimes it is possible by workaround (for example there 
could be a hole for a new member, because a data structure is aligned; or 
sometimes we can use an existing member for something else and so on), but 
generally we can't.

Second thing, which Jiri mentioned above, is switch_to macro and friends. 
switch_to is inlined to __schedule() (via context_switch()) with many 
other functions. The problem is that switch_to macro does not save RIP in 
x86_64 version (contrary to 32-bit version). So when one patches a 
function inlined to __schedule() (and thus they need to patch the very 
__schedule() because of inlining) it is perfectly possible to crash the 
kernel. New __schedule() function can easily have a different prologue and 
then the interesting thing happens. Let's have two different tasks. One 
calls __schedule(), its registers are stored in a defined order and it 
goes to sleep in switch_to macro. Then we have the second task which calls 
patched__schedule(), it goes to sleep there and as a next task the first 
one is picked. Its RSP is restored and now the registers should be 
restored as well. But the order is different in the new 
patched__schedule(), so... well you get the idea. As a result it is 
currently not possible to patch anything inlined to __schedule(). And 
there are some CVEs out there. For example LDT problem Andy discovered 
last year.

I leave aside that since 499d79559ffe ("sched/core: More notrace 
annotations") it is not even possible to patch __schedule() directly.

This is for sure something we should discuss as well. I have a more or 
less functional solution, but it modifies switch_to macro in a way which 
would easily be nacked by maintainers (I have to perform some measurements 
yet, but it is really ugly. Trust me.).

Miroslav