Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752763AbYLQRVY (ORCPT ); Wed, 17 Dec 2008 12:21:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751383AbYLQRVH (ORCPT ); Wed, 17 Dec 2008 12:21:07 -0500 Received: from BISCAYNE-ONE-STATION.MIT.EDU ([18.7.7.80]:60616 "EHLO biscayne-one-station.mit.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751365AbYLQRVF (ORCPT ); Wed, 17 Dec 2008 12:21:05 -0500 Date: Wed, 17 Dec 2008 12:19:16 -0500 (EST) From: Jeff Arnold To: Dave Jones cc: Andrew Morton , Tim Abbott , linux-kernel@vger.kernel.org, Denys Vlasenko , Anders Kaseorg , Waseem Daher , Nikanth Karthikesan , Ben Collins Subject: Re: [PATCH 0/7] Ksplice: Rebootless kernel updates In-Reply-To: <20081217035316.GA24620@redhat.com> Message-ID: References: <1228521840-3886-1-git-send-email-jbarnold@mit.edu> <20081216190740.9db323ee.akpm@linux-foundation.org> <20081217035316.GA24620@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@mit.edu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/