lkml.org 
[lkml]   [2014]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/2] kpatch: dynamic kernel patching

* Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> On Tue, May 06, 2014 at 09:32:28AM +0200, Ingo Molnar wrote:
> >
> > * Jiri Kosina <jkosina@suse.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.
>
> 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


\
 
 \ /
  Last update: 2014-05-07 14:41    [W:0.088 / U:1.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site