KSplice in Fedora?

[Jon Masters]

Hi folks,

Ksplice is very interesting and I've spoken with a few people about it
before. I met the (local to Cambridge, MA) ksplice guys several times
and recently talked to them about the kinds of things they're doing
right now. Uptrack is a nice showcase of the technology for sure.

More comments below...

On Tue, 2009-06-30 at 04:49 +0200, Kevin Kofler wrote:
> Michael Cronenworth wrote:
> >  From looking at their website, it sounds like this software can take
> > you from say kernel 2.6.27 to 2.6.29 without rebooting? Sounds like
> > black magic. I'm intrigued.

It relies upon using the existing module loading code to stop the kernel
at a given moment in time (which might have to be attempted several
times before succeeding in applying the ksplice patch, if the code paths
being updated are currently being exercised) and inserts careful jumps
to new code replacing existing functions wholesale with new ones.

> It actually can't and this is why it isn't very useful within Fedora, as we
> get big updates, not just minimal security patches.

It would be useful for stable security updates in an enterprise
distribution, and it is useful to some people in community distributions
- but there's a lot of effort involved and this is where the ksplice
guys have invested time in their infrastructure which we would have to
entirely duplicate (and engineers too) to do this in Fedora.

> KSplice can't handle that kind of updates.

Actually, it technically can.

> It can only handle small patches which don't change any data structures.

That's a load of <removed>. I'm not sure where you get this idea from -
perhaps because it's not obvious how they might achieve structural
updates and so you assume it cannot be done - but actually, they can
handle most kinds of update. They achieve this with shadow data
structure tracking and manage the ABI differences - see the paper - and
implement pre/post code hooks for things that cannot be done without a
human kernel engineer. So you can also apply initcall-time fixes by
implementing a custom pre-hook to perform what would happen at boot.

But anyway, yes, it gets complex. And I've no doubt that for the Ubuntu
kernel they're doing this for at the moment they have some of the kernel
engineers they have on staff actively writing pre/post hooks.

> So the official Fedora kernel updates will never be
> suitable to be distributed through KSplice.

That's not technically true either. It's just not practical. We would
need a much larger team of people and all of the infrastructure tools
developed by the ksplice guys. And it's indeterminate what the end goal
would be from that - most people are happy to reboot occasionally, and
those who are not can already pay Ksplice, Inc. to make updates for
them. I'm not sure this is something Fedora can practically offer.

Also - for those kernel folks reading. Don't discount ksplice because it
sounds ugly. Tim and Waseem really do get it, and they know what they're
doing - and they're actively engaging with upstream to get the bits that
could be in the mainline kernel in there (ksplice doesn't require any
existing kernel modifications because it also injects its own code
during the ksplice patch application as part of the wrapper module).

I suggest if you're interested in "add this random code patch here" type
of kernel development/testing that you add ksplice to the toolbox.

Jon.