public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Tim Abbott <tabbott@MIT.EDU>, Jeff Arnold <jbarnold@MIT.EDU>,
	linux-kernel@vger.kernel.org,
	Denys Vlasenko <vda.linux@googlemail.com>,
	Anders Kaseorg <andersk@MIT.EDU>, Waseem Daher <wdaher@MIT.EDU>,
	Nikanth Karthikesan <knikanth@suse.de>,
	Ben Collins <bcollins@ubuntu.com>
Subject: Re: [PATCH 0/7] Ksplice: Rebootless kernel updates
Date: Tue, 16 Dec 2008 22:53:16 -0500	[thread overview]
Message-ID: <20081217035316.GA24620@redhat.com> (raw)
In-Reply-To: <20081216190740.9db323ee.akpm@linux-foundation.org>

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

  reply	other threads:[~2008-12-17  3:54 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-06  0:03 [PATCH 0/7] Ksplice: Rebootless kernel updates Jeff Arnold
2008-12-06  0:03 ` [PATCH 1/7] Make section names compatible with -ffunction-sections -fdata-sections Jeff Arnold
2008-12-06  0:03   ` [PATCH 2/7] x86: Add an option to compile " Jeff Arnold
2008-12-06  0:03     ` [PATCH 3/7] Ksplice: Make find_symbol return a struct kernel_symbol Jeff Arnold
2008-12-06  0:03       ` [PATCH 4/7] Ksplice: Add module_data_address (the analogue of module_text_address) Jeff Arnold
2008-12-06  0:03         ` [PATCH 5/7] Ksplice: Add functions for walking kallsyms symbols Jeff Arnold
2008-12-06  0:03           ` [PATCH 6/7] Ksplice: Export symbols needed for Ksplice Jeff Arnold
2008-12-06  0:04             ` [PATCH 7/7] Ksplice: Support updating x86-32 and x86-64 Jeff Arnold
2008-12-17  5:41               ` Theodore Tso
2008-12-18  2:09                 ` Tim Abbott
2009-02-07  2:36               ` Rusty Russell
2009-02-10  1:01                 ` Tim Abbott
2009-02-04 11:35             ` [PATCH 6/7] Ksplice: Export symbols needed for Ksplice Rusty Russell
2009-02-13  1:46               ` Tim Abbott
2009-02-16  7:11                 ` Rusty Russell
2009-02-04 11:30           ` [PATCH 5/7] Ksplice: Add functions for walking kallsyms symbols Rusty Russell
2009-02-04 21:31             ` Anders Kaseorg
2009-02-04 11:21         ` [PATCH 4/7] Ksplice: Add module_data_address (the analogue of module_text_address) Rusty Russell
2009-02-04 20:48           ` Anders Kaseorg
2009-02-07 12:45             ` Rusty Russell
2009-02-04  9:26       ` [PATCH 3/7] Ksplice: Make find_symbol return a struct kernel_symbol Rusty Russell
2009-02-04  8:38     ` [PATCH 2/7] x86: Add an option to compile with -ffunction-sections -fdata-sections Rusty Russell
2009-02-04 10:26       ` Anders Kaseorg
2009-02-04 10:58         ` Rusty Russell
2009-02-04 20:50           ` Anders Kaseorg
2008-12-06  8:46   ` [PATCH 1/7] Make section names compatible " Andi Kleen
2008-12-31 19:18     ` Tim Abbott
2008-12-31 19:52       ` Andi Kleen
2008-12-31 21:59         ` Tim Abbott
2009-01-01 16:32           ` Andrew Morton
2009-01-04 19:20             ` Tim Abbott
2009-01-12 21:51               ` Andrew Morton
2009-01-12 22:11                 ` Andi Kleen
2009-02-04  8:15   ` Rusty Russell
2009-02-05  1:11     ` Anders Kaseorg
2009-02-05  2:00       ` Anders Kaseorg
2008-12-17  2:48 ` [PATCH 0/7] Ksplice: Rebootless kernel updates Tim Abbott
2008-12-17  3:07   ` Andrew Morton
2008-12-17  3:53     ` Dave Jones [this message]
2008-12-17 17:19       ` Jeff Arnold
2008-12-17  5:05     ` Tim Abbott
2008-12-17 12:09       ` Ben Collins
2008-12-17 12:06     ` Ben Collins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081217035316.GA24620@redhat.com \
    --to=davej@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andersk@MIT.EDU \
    --cc=bcollins@ubuntu.com \
    --cc=jbarnold@MIT.EDU \
    --cc=knikanth@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tabbott@MIT.EDU \
    --cc=vda.linux@googlemail.com \
    --cc=wdaher@MIT.EDU \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox