- compile the kernel without the patch, but using certain options (-ffunction-sections and -fdata-sections, to produce location-independent code). This is known as the pre code.
- compile the kernel with the patch and same options, producing the post code.
- perform a binary diff between pre and post to figure out what changed; extract the changed functions and package them up into their own module.
- perform a binary diff between the running kernel, known as run, and the pre code. This is the run-pre matching stage, and it has two goals: to verify the assumption that they are fundamentally the same, and to get the symbol addresses out of the running kernel. (Since pre was compiled with slightly different options, run and pre don't match up perfectly; the paper explains how they can safely differ.)
- use the symbol addresses learned during run-pre matching to patch the post code
- stop the machine at a safe point (no functions which are being updated can be on any thread's call stack)
- load the post code into the running kernel as a new module, inserting jump instructions at the beginnings of obsolete functions being replaced.
KSplice seems to be a interesting concept, but seems like the product/service is quite an unfit for the domain they are operating in (Linux Kernel updates).
The KSplice software is open source under GNU, so why not a community behind KSplice's technology simply package these (just like you would deb or rpm packages) and publish them freely (instead of having to pay KSplice, Inc simply to convert these diff's in to KSplice format).
The technology is wonderful, and I am very glad they open sourced it as well, but I am just wondering why they made it a Inc (assuming it's for-profit with their subscription service) instead of making it a open source project.
The process they follow to apply a patch is:
- compile the kernel without the patch, but using certain options (-ffunction-sections and -fdata-sections, to produce location-independent code). This is known as the pre code.
- compile the kernel with the patch and same options, producing the post code.
- perform a binary diff between pre and post to figure out what changed; extract the changed functions and package them up into their own module.
- perform a binary diff between the running kernel, known as run, and the pre code. This is the run-pre matching stage, and it has two goals: to verify the assumption that they are fundamentally the same, and to get the symbol addresses out of the running kernel. (Since pre was compiled with slightly different options, run and pre don't match up perfectly; the paper explains how they can safely differ.)
- use the symbol addresses learned during run-pre matching to patch the post code
- stop the machine at a safe point (no functions which are being updated can be on any thread's call stack)
- load the post code into the running kernel as a new module, inserting jump instructions at the beginnings of obsolete functions being replaced.