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

[Ingo Molnar]

* Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:

> On Tue, May 06, 2014 at 09:32:28AM +0200, Ingo Molnar wrote:
> > 
> > * Jiri Kosina <jkosina@xxxxxxx> 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.
> 
> Yes, in general we want to avoid data changes.  In practice, we expect
> most patches to be small, localized security fixes, so it shouldn't be
> an issue in most cases.
> 
> Currently the kpatch tooling detects any compile-time changes to 
> static data and refuses to build the patch module in that case.
> 
> But there's no way to programmatically detect changes to dynamic 
> data. Which is why the user always has to be very careful when 
> selecting a patch.

And since this is about the system kernel it's dead easy to mess up a 
new kernel function and make the system unbootable - so it's not like 
'be careful' isn't something implied already.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/