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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ