Re: [PATCH RFC 0/2] livepatch: patch creation tooling proposal

From: Miroslav Benes <mbenes@suse.cz>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: live-patching@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Joerg Roedel <jroedel@suse.de>,
	jkosina@suse.cz, jeyu@redhat.com, pmladek@suse.cz
Subject: Re: [PATCH RFC 0/2] livepatch: patch creation tooling proposal
Date: Thu, 10 Nov 2016 16:48:33 +0100 (CET)	[thread overview]
Message-ID: <alpine.LNX.2.00.1611101640540.12314@pobox.suse.cz> (raw)
In-Reply-To: <20161110153608.jsxlygej4r3ux42g@treble>

On Thu, 10 Nov 2016, Josh Poimboeuf wrote:

> On Thu, Oct 27, 2016 at 09:35:48AM -0500, Josh Poimboeuf wrote:
> > So here's my proposal: use the existing kernel build infrastructure.  If
> > klp relocations are needed, manually specify them with a new
> > klp_module_reloc struct and corresponding KLP_MODULE_RELOC macro.  Then
> > run a post-processing tool called klp-convert which converts those
> > klp_module_reloc structs into the sections, relocations, and symbols
> > needed by the klp runtime code.
> 
> I think the biggest blocker for this approach is detecting gcc
> optimizations which break function ABI, i.e. Miroslav's presentation:
> 
>   http://www.linuxplumbersconf.org/2016/ocw//system/presentations/3573/original/pres_gcc.pdf
> 
> Right now we have no way of finding all such cases.
> 
> I think our options are:
> 
> 1) Find a way for gcc to report when function ABI has been broken;

This is the one I'd like to pursue in parallel to 3). But it is 
going to be long way I imagine.

> 2) Disable all gcc optimizations which can break function ABI.  Not sure
>    if this is even possible, but if so, we'd need to quantify the
>    performance impact.  (Note we might be able to leave some options
>    enabled if they result in a function name change (e.g.,
>    -fpartial-inlining, -fipa-sra, -fipa-cp)); or

I don't think this is possible. I mean technically possible, because 
I'm almost sure some optimizations cannot be disabled easily. And also 
performance-wise. It could have a serious impact on the kernel with 
CONFIG_LIVEPATCH enabled.

I consider this option a last resort.

> 3) Stay with the status quo (kpatch-build?), since it has detection of
>    such optimizations "built in".

Also possible. We could explore the usability of Joerg's asmtool for the 
purpose.

https://github.com/joergroedel/asmtool

It could be useful even if for the detection of changed functions.

> Does anybody want to take ownership of this patch set and/or try to
> explore the options further?  I don't have any more bandwidth right now
> (mainly due to the consistency model and porting objtool to DWARF).

Sure. I can take it. I tried to write a similar tool, I saw kpatch-build 
sources and have a clue how it all works. On the other hand, no promises 
about a timeline.

Miroslav