linux-kernel - Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers

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: <C78F7BBA-860A-412D-B2B7-5028C5540695@gmail.com>
Date: Sun, 29 Sep 2024 07:12:53 +0800
From: Alan Huang <mmpgouride@...il.com>
To: Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Boqun Feng <boqun.feng@...il.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 LKML <linux-kernel@...r.kernel.org>,
 RCU <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>,
 Steven 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>
Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard
 pointers

2024年9月29日 06:10，Alan Huang <mmpgouride@...il.com> wrote：
> 
> 2024年9月28日 06:18，Jonas Oberhauser <jonas.oberhauser@...weicloud.com> wrote：
>> 
>> 
>> 
>> Am 9/27/2024 um 10:10 PM schrieb Mathieu Desnoyers:
>>> On 2024-09-27 21:23, Jonas Oberhauser wrote:
>>> [...]
>>>> That idea seems to be confirmed by this (atrocious, not to be copied!) example:
>>>> 
>>>> int fct_escape_address_of_b(void)
>>>> {
>>>>     int *a, *b;
>>>> 
>>>>     do {
>>>>         a = READ_ONCE(p);
>>>>         asm volatile ("" : : : "memory");
>>>>         b = READ_ONCE(p);
>>>>     } while (a != b);
>>>> 
>>>>     // really really hide b
>>>>     int **p = &b;
>>>>     OPTIMIZER_HIDE_VAR(p);
>>>> 
>>>>     asm volatile ("" : : : "memory");
>>>>     return *b;
>>>> }
>>>> 
>>>> This also does not generate any additional instructions, unlike just using OPTIMIZER_HIDE_VAR(b).
>>>> 
>>>> What is the advantage of defining OPTIMIZE_HIDE_VAR the way it currently works instead of like above?
>>> Did you try it on godbolt.org ? Does it have the intended effect ?
>> 
>> I certainly did try and certainly read it as having the intended effect, otherwise I wouldn't have written that it seems confirmed.
>> 
>> However, just because my eyes read it doesn't mean that's what happened, and even if it happened doesn't mean that it is guaranteed to happen.
>> 
>>> By the looks of it, you're just creating another version of @b called
>>> "p", which is then never used and would be discarded by further
>>> optimization. >
>>> I'm unsure what you are trying to achieve here.
>> 
>> Simply put I'm trying to let the compiler think that I leaked the address of b. After that, the memory barrier should let it think that the b after the memory barrier might not be the same as the one before it (which was equal to a), forcing it to read from b.
>> 
>> However, I suppose on second thought that that might not be enough, because the compiler could still simply do b = a right after exiting the while loop.
>> 
>> And that is true no matter what we put behind the while loop or before the condition, as long as the condition compares a and b, right after it the compiler can do b = a. Just took me a while to see :))
>> 
>> I'm not sure why gcc does the b=a with the normal OPTIMIZER_HIDE_VAR but (as far as I read the code) doesn't do it with the above. Maybe just a weird corner case...
> 
> Let the p to be a static variable out of the function will make a difference.
> 
> Or the following:
> 
> int **p = &b;
> barrier_data(p);

Or the following:

	int **t = &b;
	WRITE_ONCE(t, &b);
	barrier();
 	return *b;

also works.

> 
> also works.
> 
> BTW, barrier_data(&b) generates more instructions than godbolt when build the kernel.
> 
>> 
>> Have fun,
>> jonas