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:	Thu, 12 Feb 2015 13:36:20 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Josh Poimboeuf <jpoimboe@...hat.com>,
	Ingo Molnar <mingo@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
	Seth Jennings <sjenning@...hat.com>,
	Vojtech Pavlik <vojtech@...e.cz>
Subject: Re: [RFC PATCH 6/9] livepatch: create per-task consistency model

On Thu, Feb 12, 2015 at 01:25:14PM +0100, Jiri Kosina wrote:
> On Thu, 12 Feb 2015, Peter Zijlstra wrote:

> > FWIW, the barriers in klp_update_task_universe() and 
> > klp_set_universe_goal() look like complete crack, and their comments are 
> > seriously deficient.
> 
> These particular barriers seem correct to me; you basically need to make 
> sure that whenever a thread with TIF_KLP_NEED_UPDATE goes through 
> do_notify_resume(), it sees proper universe number to be converted to.

I'm not seeing how they're going to help with that.

The comment should describe the data race and how the barriers are
making it not happen.

putting wmb after a store and rmb before a read doesn't avoid the reader
seeing the old value in any universe I know of.

Barriers are about order, you need two consecutive stores for a wmb to
make sense, and two consecutive reads for an rmb, and if they're paired
the stores and reads need to be to the same addresses.

Without that they're pointless.

The comment doesn't describe which two variables are ordered how.
--
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