linux-kernel - Re: [PATCHv3 2/3] kernel: add support for live patching

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:	Mon, 24 Nov 2014 14:31:40 +0100
From:	Vojtech Pavlik <vojtech@...e.cz>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Jiri Kosina <jkosina@...e.cz>, Seth Jennings <sjenning@...hat.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Petr Mladek <pmladek@...e.cz>, Miroslav Benes <mbenes@...e.cz>,
	Christoph Hellwig <hch@...radead.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	live-patching@...r.kernel.org, x86@...nel.org, kpatch@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHv3 2/3] kernel: add support for live patching

On Mon, Nov 24, 2014 at 02:26:08PM +0100, Thomas Gleixner wrote:
> On Mon, 24 Nov 2014, Jiri Kosina wrote:
> > On Mon, 24 Nov 2014, Thomas Gleixner wrote:
> > > How is determined whether a change can be applied w/o a consistency
> > > mechanism or not?
> > 
> > By a human being producing the "live patch" code.
> > 
> > If the semantics of the patch requires consistency mechanism to be applied 
> > (such as "old and new function must not run in parallel, because locking 
> > rules would be violated", or "return value from a function that is being 
> > called in a loop is changing its meaning", etc.), then this first naive 
> > implementation simply can't be used.
> > 
> > For simple things though, such as "add a missing bounds check to sys_foo() 
> > prologue and return -EINVAL if out-of-bounds", this is sufficient.
> > 
> > It's being designed in a way that more advanced consistency models (such 
> > as the ones kgraft and kpatch are currently implementing) can be built on 
> > top of it.
> > 
> > The person writing the patch would always need to understand what he is 
> > doing to be able to pick correct consistency model to be used. I 
> > personally think this is a good thing -- this is nothing where we should 
> > be relying on any kinds of tools.
> 
> But why want we to provide a mechanism which has no consistency
> enforcement at all?
> 
> Surely you can argue that the person who is doing that is supposed to
> know what he's doing, but what's the downside of enforcing consistency
> mechanisms on all live code changes?

The consistency engine implementing the consistency model is the most
complex part of the live patching technology. We want to have something
small, easy to understand pushed out first, to build on top of that.

Plus we're still discussing which exact consistency model to use for
upstream live patching (there are many considerations) and whether one
is enough, or whether an engine that can do more than one is required.

The consistency models of kpatch and kGraft aren't directly compatible.

I think we're on a good way towards a single model, but we'll see when
it's implemented within the live patching framework just posted.

-- 
Vojtech Pavlik
Director SUSE Labs
--
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/