Hello,
I've put together an automatic system for applying kernel security patches

to the Linux kernel without rebooting it, and I wanted to share this

system with the community in case others find it useful or interesting.
Here's the summary:  The system takes as input a kernel security patch

(which can be a unified diff taken directly from Linus' GIT tree) and the

source code corresponding to the running kernel, and it automatically

creates a set of kernel modules to perform the update.  The running kernel

does not need to have been customized in advance in any way.  To be fully

automatic, the system cannot be used to apply patches that introduce

semantic changes to data structures, but most Linux kernel security

patches don't make these kinds of changes.  I've evaluated the system

against various kernel versions and security vulnerabilities, and the

system can automatically apply 84% of the significant kernel security

patches from May 2005 through December 2007.
I've been pursuing this project because I don't like dealing with reboots

whenever a new local kernel security vulnerability is discovered.  The

rebootless update practices/systems that are already out there require

manually constructing an update (through a process that can be tricky and

error-prone), and they tend to have other disadvantages as well (such as

requiring a custom kernel, not handling inline functions properly, etc).

This new system works on existing kernels, and it simply takes a unified

diff as input and does the rest on its own.
The system's website is http://web.mit.edu/ksplice.
The GIT repository, code tarball, and binary tarballs are available here:

http://web.mit.edu/ksplice/ksplice.git

http://web.mit.edu/ksplice/dist/ksplice-src.tar.gz

http://web.mit.edu/ksplice/dist/ksplice-bin-i386.tar.gz

http://web.mit.edu/ksplice/dist/ksplice-bin-x86_64.tar.gz
A document describing how the system works is available here:

http://web.mit.edu/ksplice/doc/ksplice.pdf
Any feedback wou...
[ message continues ]

This sounds really interesting. I just wanted to test on my Gentoo system with

kernel 2.6.25. The tarball creation works, but applying the change brings an

error to syslog:
ksplice_242e9pfc_helper: Unknown symbol init_mm
Any chance to get a fix for that?

--

Regards,

Chris

--

Sorry.  (In 2.6.25, init_mm is marked as an unused symbol, and so whether

it is exported depends on whether CONFIG_UNUSED_SYMBOLS is enabled).
I've committed a change which should fix this problem.  You can get get

the new version (0.8.1) from http://web.mit.edu/ksplice/dist/ or from Git.

(I haven't yet made the new version the default, so you won't receive it

from the main Ksplice page).
Jeff Arnold

jbarnold@mit.edu
--

This time I get the following in syslog:
ksplice_h: Preparing and checking ksplice_oq7ne7l6

ksplice: Aborted. (stack check: to-be-replaced code is busy)
I tried the example from your website (modifying printk).

--

Regards,

Chris

--

This problem has now been resolved (a broken wireless card apparently left

a kernel thread in an unusual state, which led to Ksplice aborting the

upgrade).  Christian now has Ksplice working on his system.
If anyone else tries the software and encounters trouble, please let me

know.
Thanks,
Jeff Arnold

jbarnold@mit.edu

--

Sounds interesting.  You should consider bringing the kernel module

up to kernel coding standards and submitting it for mainline. That

would be the best way to get more users and testers.
Have you also considered to turn it into a generic incremental binary

linker too? I guess most of the infrastructure needed for it is

already there. Even though gold looks very promising long link times

can be still a problem in development.
-Andi

--

I'm certainly interested in bringing the code up to kernel coding

standards (for example, I'd be happy to address any issues with the code

that are brought to my attention).  I'm not sure whether submitting it for

mainline makes sense since the software doesn't significantly benefit from

being bundled with the kernel.
Instead, it might be more important to 1) package the userspace

update-construction software for common Linux distributions to make it

easily available to interested users, and 2) to provide binary kernel

updates for common distribution kernels so that users can simply sign up

and get fewer "your machine needs to be rebooted now for an update to take

effect" notifications.
I've considered modifying the system for use in other contexts, but I

don't think that I'll get around to such a project anytime soon; my

current focus is on making it easier for people to perform rebootless

kernel security updates.
Jeff Arnold

jbarnold@mit.edu

--

To be honest you weren't the first to come up with something like this

(although you're the first to post to l-k as far as I know). But the

usual problem of something that is kept out of tree is that it

eventually bitrots and gets forgotten. The only sane way to make such
(2) is a incredibly large amount of work longer time. And when

distributions merge your feature they become committed to it so even if

you go away they would still need to maintain it on their own. Since

they understand how much work this is they likely won't do it in the

first place. Really it's far  better to just merge if you want it to

make it out of the "toy" stage.
-Andi

--

You're probably right.
I'm willing to undertake the project of bringing the code up to kernel

coding standards so that it can eventually be considered for mainline.

I'll plan on undertaking this project if I don't receive feedback that I

shouldn't do so.
If people have concerns about the high-level design of the system, it

would be useful for me to know that information sooner rather than later.
If there's anything that I can do to facilitate feedback at this stage,

please let me know.
Thanks for the advice.
Jeff Arnold

jbarnold@mit.edu

--

* Jeff Arnold <jbarnold@MIT.EDU> wrote:
Great think :)

I'd actually like to see it mainline tree (I prefer vanilla kernel
I didn't have the time for an deeper study yet, but as you already

mentioned, there're lots of limitations which can make it harmful:

as soon as interfaces chance, you're in *big* trouble. There should

be a way for finding them (automatically). Maybe extract the

interface signatures (including structs!) so some appropriate place

next to the kernel, so they can be checked before (re)loading the

module.
Ah, of course you can't change code that's not an dynamic module :(
Even this goes OT now - I'd really prefer more things in userland,

eg. network- or synthetic filesystems, crypt stuff, etc - so

there would be less to update within the kernel ;-o
cu

--

---------------------------------------------------------------------

 Enrico Weigelt    ==   metux IT service - http://www.metux.de/

---------------------------------------------------------------------

 Please visit the OpenSource QM Taskforce:

 	http://wiki.metux.de/public/OpenSource_QM_Taskforce

 Patches / Fixes for a lot dozens of packages in dozens of versions:

	http://patches.metux.de/

---------------------------------------------------------------------

--

Actually there is a mature discipline around data changes that

dates back to before Unix v7, but it's off-topic for this

discussion: it would make the changes too big (;-))
  If anyone is interested, see http://multicians.org/stachour.html

and/or send me mail
--dave (reading LKML when he should be working) c-b

--

David Collier-Brown            | Always do right. This will gratify

Sun Microsystems, Toronto      | some people and astonish the rest

davecb@sun.com                 |                      -- Mark Twain

(905) 943-1983, cell: (647) 833-9377, (800) 555-9786 x56583

bridge: (877) 385-4099 code: 506 9191#

--

Is there a ksplice mailing list?  I did not see mention of one on the

web page.
Cheers,

Dan
--

                     /--------------- - -  -  -   -   -

                     |  Dan Noe

                     |  http://isomerica.net/~dpn/

--

I've now created one:

http://mailman.mit.edu/mailman/listinfo/ksplice-devel
Jeff Arnold

jbarnold@mit.edu

--

On Wed, 23 Apr 2008 14:59:05 -0400 (EDT)
Awesome. Please note that reading this, I thought at first that the set of

kernel modules were in fact, updated kernel modules (i.e. necessary unloading/

loading of modules) which I understood was not the case after reading your

PDF. After checking with a friend of mine, he understood it like I did.

Perhaps :
- it automatically creates a set of kernel modules to perform the update.

+ it automatically creates a set of kernel modules containing the kernel

+ functions touched by the update, and arranges for the running kernel to

+ use the new functions from now on.
It really looks like a non intrusive way of achieving superior uptime.
Congrats ! 
Best,
Francois

--