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: <alpine.LRH.2.00.1405021030540.22053@twin.jikos.cz>
Date:	Fri, 2 May 2014 10:37:53 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
cc:	Seth Jennings <sjenning@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	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, 1 May 2014, Josh Poimboeuf wrote:

> Since Jiri posted the kGraft patches [1], I wanted to share an
> alternative live patching solution called kpatch, which is something
> we've been working on at Red Hat for quite a while.

Hi Josh, Seth,

thanks a lot for following up to our RFC with your submission, I am pretty 
sure this will help to energize the discussion and will provoke ideas for 
further improvements.

[ ... snip ... ]
> kpatch vs kGraft
> ----------------
> 
> I think the biggest difference between kpatch and kGraft is how they
> ensure that the patch is applied atomically and safely.
> 
> kpatch checks the backtraces of all tasks in stop_machine() to ensure
> that no instances of the old function are running when the new function
> is applied.  I think the biggest downside of this approach is that
> stop_machine() has to idle all other CPUs during the patching process,
> so it inserts a small amount of latency (a few ms on an idle system).

Completely agreed with your comparative analysis, thanks for a nice 
summary.

Additional thing that I believe is important to add here: with the 
"stop-machine / check all tasks" aproach, there might be situations where 
you'll always fail to patch the system; if there is a long-time sleeper in 
the patched callchain, such a single sleeper is enough to make the 
patching of the whole system impossible.

With the lazy/gradual aproach implemented in kGraft, the whole system is 
gradually moving towards "fully patched" state and once all the sleepers 
blocking the process wake up, it ultimately converges to the fully patched 
state.

Thanks,

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