Message-ID: <20141107130654.GC4071@treble.redhat.com>
Date:	Fri, 7 Nov 2014 07:06:54 -0600
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Vojtech Pavlik <vojtech@...e.cz>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Seth Jennings <sjenning@...hat.com>,
	Jiri Kosina <jkosina@...e.cz>,
	Steven Rostedt <rostedt@...dmis.org>,
	live-patching@...r.kernel.org, kpatch@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Kernel Live Patching

On Fri, Nov 07, 2014 at 01:48:45PM +0100, Vojtech Pavlik wrote:
> On Fri, Nov 07, 2014 at 06:31:54AM -0600, Josh Poimboeuf wrote:
> > On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
> > > On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
> > > 
> > > > On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
> > > > > I don't think this specific example was generated. 
> > > > > 
> > > > > I also don't think including the whole kpatch automation into the kernel
> > > > > tree is a viable development model for it. (Same would apply for kGraft
> > > > > automation.)
> > > > 
> > > > Why?  We (IMHO incorrectly) used the argument of tight coupling to put
> > > > perf into the kernel tree.  Generating kernel live patches is way more
> > > > integrated that it absolutely has to go into the tree to be able to do
> > > > proper development on it in an integrated fashion.
> > > 
> > > One reason is that there are currently at least two generators using
> > > very different methods of generation (in addition to the option of doing
> > > the patch module by hand), and neither of them are currently in a state
> > > where they would be ready for inclusion into the kernel (although the
> > > kpatch one is clearly closer to that).
> > 
> > What generator does kGraft have?  Is that the one that generates the
> > source patch, or is there one that generates a binary patch module?
> 
> The generator for kGraft:
> 
> 	* extracts a list of changed functions from a patch (rather naïvely so far)
> 	* uses DWARF debuginfo of the old kernel to handle things like inlining
> 	  and create a complete list of functions that need to be replaced
> 	* compiles the kernel with -fdata-sections -ffunction-sections
> 	* uses a modified objcopy to extract functions from the kernel
> 	  into a single .o file
> 	* creates a stub .c file that references those functions
> 	* compiles the .c and links with the .o to build a .ko
> 
> The main difference is in that the kGraft generator doesn't try to
> compare the old and new binary objects, but rather works with function
> lists and the DWARF info of the old code and extracts new functions from
> the new binary.

Thanks, interesting.  Sounds like we're mostly on the same page here.

> 
> However, as I said before, we have found enough trouble around eg.
> IPA-SRA and other optimizations that make any automated approach fragile
> and in our view more effort than benefit. Hence, we're intend to use the
> manual way of creating live patches until proven that we were wrong in
> this assessment. :)

Yeah.  We've already put in a lot of effort to support the gcc optimizations
like IPA-SRA, partial inlining, static variable renaming, etc.  And also
added support for many kernel special sections.

For now, at least, it works very well, and we find that generation is
_much_ easier and less error-prone than the manual approach.  So in our
experience, the benefits far outweigh the effort.

But I do agree that it's fragile, and at the mercy of any future gcc
optimization features.  Which is why I like our current approach of
supporting the manual approach as well.  The manual approach isn't
optimal, but it is a nice backup solution for us in case something
causes the generator to break.

-- 
Josh
--
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/

Powered by blists - more mailing lists