linux-kernel - Re: [RFC PATCH 0/9] livepatch: consistency model

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] [day] [month] [year] [list]

Message-ID: <20150310213017.GA14122@treble.redhat.com>
Date:	Tue, 10 Mar 2015 16:30:17 -0500
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Seth Jennings <sjenning@...hat.com>,
	Vojtech Pavlik <vojtech@...e.cz>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>, jslaby@...e.cz, mbenes@...e.cz
Subject: Re: [RFC PATCH 0/9] livepatch: consistency model

On Tue, Mar 10, 2015 at 05:02:20PM -0400, Jiri Kosina wrote:
> On Tue, 10 Mar 2015, Josh Poimboeuf wrote:
> 
> > Just an update on the status of this RFC.  Thanks to everybody for all 
> > the useful comments.  I plan to incorporate the resulting changes in an 
> > eventual v2 of this patch set.
> > 
> > But, as Peter and Ingo have pointed out, stack traces are indeed
> > unreliable.  I have some ideas about how to improve them, coming soon in
> > another RFC, which will be a prerequisite for this patch set.
> 
> Thanks for the update. Just FYI, in parallel, Jiri Slaby (with help from a 
> few other people) (added to CC) is working on RFC on a per-thread patching 
> on top of the livepatching core, so that we can actually compare pros and 
> cons of both aproaches and implementations.
> 
> It might still take some time before its finalized and sent out as a RFC, 
> as I'd like it to also contain the "fake signal" task handling suggested 
> by Ingo. Miroslav is working on that part.

Ok, thanks for the heads up.

I think the two approaches are complementary.  _If_ we can make stack
checking safe, then IMO it's by far the most lightweight and least
disruptive option, so it should be the first wave of attack.  We can use
that to transition most of the tasks.

Any remaining "straggler" tasks (which are either sleeping on a patched
function or have a potentially unreliable stack) can use something else
like fake signals.

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