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]

Date:	Tue, 16 Dec 2008 22:53:16 -0500
From:	Dave Jones <davej@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Tim Abbott <tabbott@....EDU>, Jeff Arnold <jbarnold@....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, Dec 16, 2008 at 07:07:40PM -0800, Andrew Morton wrote:

 > I'd have _thought_ that distros and their high-end customers would be
 > interested in it, but I haven't noticed anything from them.  Not that
 > this means much - our processes for gathering this sort of information
 > are rudimentary at best.  Has your team been in contact with distros?
 > Are Suse shipping it, or planning to?
 > 
 > (cc's a few more distro people)

I'm not exactly enamoured by this tbh.
It's a neat hack, but the idea of it being used by even a small percentage
of our users gives me the creeps.

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.
The Fedora position on it has been 'you keep both pieces if something breaks'
in the same way we don't support someone who hand-built their own kernel.
I understand ksplice now taints the kernel when it applies a patch, which
is a step in the right direction, but we don't always get to see
tainted flags in bug reports (the non-oops variants for eg).

If distros can't get security updates out in a reasonable time, fix
the process instead of adding mechanism that does an end-run around it.

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

Having seen some of the non-ksplice runtime patches that appear in the
wake of a new security hole, I can't say I have a lot of faith.
Perhaps if there was a kernel.org sanctioned ksplice functionality, 
then such patches would get better review before being deployed. Dunno.

	Dave

-- 
http://www.codemonkey.org.uk
--
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/