Re: [PATCH 0/7] Ksplice: Rebootless kernel updates

[Jeff Arnold]

On Tue, 16 Dec 2008, Dave Jones wrote:

Hi Dave.  Thanks for your feedback.  I thought that it might be helpful 
for me to provide some information about how Ksplice tries to address 
these concerns.

> It comes down to 'what happens when something goes wrong'.
> When the end-user is running a ksplice-patched kernel with an unknown
> number of patches, reproducability can get really complicated.

Ksplice does everything that we've been able to think of to help with 
reproducibility and debugging.

The taint flag tells you whether any Ksplice updates have been loaded.  
The list of loaded modules gives you an ID string for every Ksplice update 
that has been loaded (which, if you have a copy of those updates, tells 
you everything that Ksplice has done to the kernel, in the order that it 
has done it).

Ksplice verifies the kernel's text before applying each update to make 
sure that the kernel text exactly matches Ksplice's expectations (Ksplice 
takes into account code modifications that have already happened, such as 
from altinstructions and previous Ksplice updates).

> but we don't always get to see tainted flags in bug reports (the 
> non-oops variants for eg).

Perhaps it is possible to make taint information appear in bug reports 
more frequently?  It seems as though useful bug reports already need to 
contain quite a bit of other information.

> Which just leaves the "we can't afford downtime" argument, which leads
> me to question how well reviewed runtime patches are.

I'm not sure whether you're worried about the Ksplice code itself or the 
patches that people might apply using Ksplice.

As for the Ksplice code itself, I suppose that I can only say that we've 
done our best and we invite people to find problems in it.

If you're concerned about the patches that people might apply using 
Ksplice:  yes, I agree that writing new custom code for hot updates is 
scary.  Ksplice has, in fact, been designed around the idea of avoiding 
new code for hot updates.  88% of CVEs from May 2005 to May 2008 can be 
corrected without writing a single line of new code [1]--Ksplice 
constructs the update based entirely on the existing mainline patch.  
(The remaining CVEs require an average of roughly 20 semicolon-terminated 
new lines of code per CVE).  Updates should still be generated by someone 
competent, but we've tried to minimize the burden and risk involved.

[1] http://www.ksplice.com/cve-evaluation

Jeff Arnold
jbarnold@xxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/