All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Seth Jennings <sjenning@redhat.com>,
	Jiri Kosina <jkosina@suse.cz>, Vojtech Pavlik <vojtech@suse.cz>,
	Steven Rostedt <rostedt@goodmis.org>,
	Petr Mladek <pmladek@suse.cz>, Miroslav Benes <mbenes@suse.cz>,
	Christoph Hellwig <hch@infradead.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	live-patching@vger.kernel.org, x86@kernel.org, kpatch@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCHv3 2/3] kernel: add support for live patching
Date: Mon, 24 Nov 2014 07:24:37 -0600	[thread overview]
Message-ID: <20141124132437.GA6235@treble.redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1411241209050.6439@nanos>

On Mon, Nov 24, 2014 at 12:13:20PM +0100, Thomas Gleixner wrote:
> On Thu, 20 Nov 2014, Seth Jennings wrote:
> > This commit introduces code for the live patching core.  It implements
> > an ftrace-based mechanism and kernel interface for doing live patching
> > of kernel and kernel module functions.
> > 
> > It represents the greatest common functionality set between kpatch and
> > kgraft and can accept patches built using either method.
> > 
> > This first version does not implement any consistency mechanism that
> > ensures that old and new code do not run together.  In practice, ~90% of
> > CVEs are safe to apply in this way, since they simply add a conditional
> > check.  However, any function change that can not execute safely with
> > the old version of the function can _not_ be safely applied in this
> > version.
> 
> To be honest this sounds frightening.

The risky part of live patching is patch analysis and creation.  If the
user isn't careful with their analysis, they're playing with fire.

We'll be documenting the patch analysis steps, so that if you carefully
follow the steps, it's safe.  But that should generally be the role of
the distribution.

> How is determined whether a change can be applied w/o a consistency
> mechanism or not?

The following are not safe without consistency mechanisms:

- function prototype changes
- data structure changes
- data semantic changes: changes to how functions interact with a data
  structure, e.g. locking order

We'll be adding the consistency mechanisms later to enable function and
data consistency.  But even then you have to be very careful.

-- 
Josh

  parent reply	other threads:[~2014-11-24 13:25 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-20 22:29 [PATCHv3 0/3] Kernel Live Patching Seth Jennings
2014-11-20 22:29 ` [PATCHv3 1/3] kernel: add TAINT_LIVEPATCH Seth Jennings
2014-11-20 22:29 ` [PATCHv3 2/3] kernel: add support for live patching Seth Jennings
2014-11-21  0:22   ` Jiri Kosina
2014-11-21 14:44     ` Miroslav Benes
2014-11-21 15:00       ` Josh Poimboeuf
2014-11-21 15:46         ` Miroslav Benes
2014-11-21 16:13           ` Seth Jennings
2014-11-21 15:21     ` Josh Poimboeuf
2014-11-21 15:27       ` Jiri Kosina
2014-11-21 15:35         ` Josh Poimboeuf
2014-11-21 16:40     ` Seth Jennings
2014-11-21 17:35       ` Jiri Slaby
2014-11-21 18:29         ` Seth Jennings
2014-11-21 17:53       ` Andy Lutomirski
2014-11-21  2:39   ` Masami Hiramatsu
2014-11-25 16:39     ` Petr Mladek
2014-11-25 16:52       ` Steven Rostedt
2014-11-25 17:04         ` Petr Mladek
2014-11-25 17:16           ` Steven Rostedt
2014-11-25 19:29             ` Jiri Kosina
2014-12-03  8:09               ` Masami Hiramatsu
2014-11-24 11:13   ` Thomas Gleixner
2014-11-24 13:21     ` Jiri Kosina
2014-11-24 13:26       ` Thomas Gleixner
2014-11-24 13:31         ` Vojtech Pavlik
2014-11-24 14:25           ` Masami Hiramatsu
2014-11-24 13:31         ` Jiri Kosina
2014-11-24 13:23     ` Vojtech Pavlik
2014-11-24 13:24     ` Josh Poimboeuf [this message]
2014-11-24 13:27     ` Masami Hiramatsu
2014-11-20 22:29 ` [PATCHv3 3/3] kernel: add sysfs documentation " Seth Jennings
2014-11-21  2:49   ` Masami Hiramatsu
2014-11-21 16:41     ` Seth Jennings
2014-11-21  2:44 ` [PATCHv3 0/3] Kernel Live Patching Masami Hiramatsu

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=20141124132437.GA6235@treble.redhat.com \
    --to=jpoimboe@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=jkosina@suse.cz \
    --cc=kpatch@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mbenes@suse.cz \
    --cc=pmladek@suse.cz \
    --cc=rostedt@goodmis.org \
    --cc=sjenning@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=vojtech@suse.cz \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.