Hot-patching a Linux kernel w/o rebooting

[Joe.MacDonald@xxxxxxxxxxxxx (MacDonald, Joe)]

Hey Ted,

On Wed, 2008-04-23 at 08:41 -0400, Theodore Ts'o wrote:

> As I recall, this sort of thing generally gets Carrier Grade folks all
> hot and bothered, so I thought I would send a pointer to some really
> cool work that a friend of mine from MIT has just recently completed:

Thanks for pointing this out, it's a topic we've had more than a few
debates about in the CGL group.   There's been a couple of
implementations we've looked at in the past, but none of them have quite
reached the level where we could call them a valid PoC for registration
purposes.  Ksplice being external to the kernel (as opposed to a set of
kernel patches) really seems closer to what we actually would need to
see in order to meet the requirements of equipment providers.

Obviously since you just sent this out I haven't had time to completely
read and digest the paper, but I did have a couple of questions that
maybe you could answer quickly. 

What I've read so far makes it sound like you would use ksplice on a
target to generate a binary patch for the running kernel.  That's
appealing but not exactly practical in a large network deployment
scenario.  Is it possible to take the results of the patching process
and then transfer that binary change to other nodes?  I suppose in the
final analysis it's pretty much the same thing, there's still going to
be some scripting required.

Second, from a validation standpoint, what happens with the patched
kernel?  My concern is that now that you're running a new kernel image,
it no longer matches what is on disk and it doesn't match what will be
running the next time a reboot happens.  Is it possible with ksplice to
produce patches that would be reapplied after a restart, or to modify
the boot kernel image?  That opens up all kinds of hairy corner cases
when the running kernel isn't local and so on, so the boot-time patching
solution is probably more reliable (and that way the vendor could apply
a hot-fix quickly but then not roll out a new kernel until it had passed
all their QA process and still not worry that their machines could be
again open to attack in the interim), but this goes back to my earlier
question about keeping binary patches around so the source code doesn't
need to be applied everywhere.

Anyway, off to read the rest of the paper and the website now.  Thanks
for the heads-up.

-J.


> 
> 	http://web.mit.edu/ksplice
> 
> A technical paper describing the technology, "Ksplice: An automatic
> system for rebootless Linux kernel security updates", is available here:
> 
>        http://web.mit.edu/ksplice/doc/ksplice.pdf
> 
> Best of all, it doesn't require any kernel patches, so you can use
> Ksplice to patch a Linux kernel you currently have running on your
> system right now.  :-)
> 
> 						- Ted
> _______________________________________________
> Lf_carrier mailing list
> Lf_carrier at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lf_carrier


Joe MacDonald, Member of Technical Staff, Wind River
direct 613.270.5750  mobile 613.291.7421  fax 613.592.2283   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lf_carrier/attachments/20080423/822f97a2/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.linux-foundation.org/pipermail/lf_carrier/attachments/20080423/822f97a2/attachment.pgp