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: <CAHk-=whteT=CDW09TMk4wwwYs+qvcAKQUfw8+1D-e8H4XhFs3A@mail.gmail.com>
Date: Fri, 27 Sep 2024 13:24:07 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Boqun Feng <boqun.feng@...il.com>, 
	linux-kernel@...r.kernel.org, rcu@...r.kernel.org, linux-mm@...ck.org, 
	lkmm@...ts.linux.dev, "Paul E. McKenney" <paulmck@...nel.org>, 
	Frederic Weisbecker <frederic@...nel.org>, Neeraj Upadhyay <neeraj.upadhyay@...nel.org>, 
	Joel Fernandes <joel@...lfernandes.org>, Josh Triplett <josh@...htriplett.org>, 
	"Uladzislau Rezki (Sony)" <urezki@...il.com>, rostedt <rostedt@...dmis.org>, 
	Lai Jiangshan <jiangshanlai@...il.com>, Zqiang <qiang.zhang1211@...il.com>, 
	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>, 
	Waiman Long <longman@...hat.com>, Mark Rutland <mark.rutland@....com>, 
	Thomas Gleixner <tglx@...utronix.de>, Kent Overstreet <kent.overstreet@...il.com>, 
	Vlastimil Babka <vbabka@...e.cz>, maged.michael@...il.com, 
	Neeraj Upadhyay <neeraj.upadhyay@....com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers

On Fri, 27 Sept 2024 at 12:28, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Dammit, people, read the code I posted.

Actually, no, apologies. You were right, and I was wrong.

It does need both of the sources of the comparison to be hidden,
because while even hiding just one side makes the comparison result
"meaningless" as far as the compiler is concerned, the compiler will
still have generated a pseudo for the hidden value, and might decide
that it can re-use that pseudo for the non-hidden pointer if the two
then match.

So yeah, the example function I posted should be safe, but my "you can
probably make do with hiding just one side" was actually a bogus and
invalid optimization. You do need to hide both sides. Not just for
clarity, but for correctness.

             Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ