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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.0812170046550.27419@vinegar-pot.mit.edu>
Date:	Wed, 17 Dec 2008 12:19:16 -0500 (EST)
From:	Jeff Arnold <jbarnold@....EDU>
To:	Dave Jones <davej@...hat.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Tim Abbott <tabbott@....edu>, linux-kernel@...r.kernel.org,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Anders Kaseorg <andersk@....edu>,
	Waseem Daher <wdaher@....edu>,
	Nikanth Karthikesan <knikanth@...e.de>,
	Ben Collins <bcollins@...ntu.com>
Subject: Re: [PATCH 0/7] Ksplice: Rebootless kernel updates

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@....edu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/