linux-kernel - Re: [RFC PATCH 0/2] kpatch: dynamic kernel 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]

Message-ID: <1399603544.2272.6.camel@pippen.local.home>
Date:	Thu, 08 May 2014 22:45:44 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	David Lang <david@...g.hm>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Jiri Kosina <jkosina@...e.cz>,
	Seth Jennings <sjenning@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>, Jiri Slaby <jslaby@...e.cz>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching

On Thu, 2014-05-08 at 18:46 -0700, David Lang wrote:
> On Wed, 7 May 2014, Ingo Molnar wrote:

> It's possible to have two versions of code that each work independently, but 
> that you can't switch between easily on the fly.
> 
> If the new code assumes a lock is held that the old code didn't take, then when 
> you switch, you are eventually going to hit a case where the new code trys to 
> release a lock it doesn't hold.

But we are replacing full functions here. Never half way through. Thus,
there should never be "old code didn't take", because we replace the
entire function. If the new code expects a lock to be held where the old
code did not, there's nothing changing anything that leads up to this
new code. The lock still won't be taken.

A patch that expects that wont work on a reboot either.

> 
> detecting all possible cases progromatically seems close to impossible.
> 
> but this means that there are two categories of patches
> 
> 1. patches that are safe to put in a kernel that you are going to boot from
> 
> 2. patches that are able to be applied on the fly
> 
> and the tool isn't going to be able to tell you which category the patch is in. 
> It can identify some of the items that make it unlikely or impossible for the 
> patch to belong to #2, but don't rely on the tool catching all of them

I agree that live patching is going to be a bit trickier than patches
that are applied for reboot. And I also agree that no tool could
determine if the patch can be applied live even if it could be applied
safely for reboot. To do so would probably be on the difficulty scale of
the halting problem.

-- Steve


--
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/