Get to know Ksplice: kernel patching was never this easy.

Re:Get to know Ksplice: kernel patching was never this easy. by malkia on Tuesday July 27, 2010 @06:51PM (#1553009)

Cool. Correct me if I'm wrong, this is how I think the article describes it: - Stop the machine (one cpu running, the other ones are stopped). - Verify in all thread stacks whether the address range of the "C" function to be patched (begining to the end) to be patched is not referenced in the stack - e.g. if some function have to return to the said one (there might be false positives). - Put the new code in a free memory for execution. Change the first 5 bytes (x86) of the old function with JMP to the new function (granted the function should be at least 5 bytes).

Function changes that won't work: - Change to the function return type. - Change to the function argument list.

Things to be aware of: - If the same function is to be patched again, then you should check the stack for all pervious versions of the function (the stack might be in the old function, doing a JMP to a newer version that's doing another JMP to a newer function, etc.).

What else I might be missing?

Still don't know how they deal with data structures...

In Common Lisp, one can update CLOS objects, but these beasts are full of metadata, and only the compiler knows the inner parts.

Still quite interresting.

[ Parent | on HN ]

Re:Get to know Ksplice: kernel patching was never this easy. by chwahoo on Tuesday July 27, 2010 @07:14PM (#1553043)

I believe changes to a function's return type and argument list should be supported. The caller of such a function would need to have been modified, so if the caller is also not "active" (on the callstack), then the update should be typesafe.

They do have limited support for type changes to data - e.g., adding a field to a struct. These must be performed using a "shadow data structure" which holds fields that were added to the original structure. This would cause patches to diverge a bit from the original kernel versions.

However, since Ksplice aims primarily to support security patches, I suspect that both function signature and type changes are less common than they would be for general OS (or application) evolution.

[ Parent | on HN ]