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: <9dec7f8d-16c0-4122-bf03-c16bd616ca15@huaweicloud.com>
Date: Wed, 8 Jan 2025 18:39:12 +0100
From: Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
To: paulmck@...nel.org, Alan Stern <stern@...land.harvard.edu>
Cc: parri.andrea@...il.com, will@...nel.org, peterz@...radead.org,
 boqun.feng@...il.com, npiggin@...il.com, dhowells@...hat.com,
 j.alglave@....ac.uk, luc.maranget@...ia.fr, akiyks@...il.com,
 dlustig@...dia.com, joel@...lfernandes.org, urezki@...il.com,
 quic_neeraju@...cinc.com, frederic@...nel.org, linux-kernel@...r.kernel.org,
 lkmm@...ts.linux.dev, hernan.poncedeleon@...weicloud.com
Subject: Re: [RFC] tools/memory-model: Rule out OOTA



Am 1/7/2025 um 7:47 PM schrieb Paul E. McKenney:
> On Tue, Jan 07, 2025 at 11:09:55AM -0500, Alan Stern wrote:
> 
>> (For example, in a presentation to the C++ working group last year, Paul
>> and I didn't try to show how to extend the C++ memory model to exclude
>> OOTA [other than by fiat, as it does now].  Instead we argued that with
>> the existing memory model, no reasonable compiler would ever produce an
>> executable that could exhibit OOTA and so the memory model didn't need
>> to be changed.)
> 
> Furthermore, the LKMM design choice was that if a given litmus test was
> flagged as having a data race, anything might happen, including OOTA.

Note that there is no data race in this litmus test.
There is a race condition on plain accesses according to LKMM,
but LKMM also says that this is *not* a data race.

The patch removes the (actually non-existant) race condition by saying 
that a critical section that is protected from having a data race with 
address dependency or rmb/wmb (which LKMM already says works for 
avoiding data races), is in fact also ordered and therefore has no race 
condition either.

As a side effect :), this happens to fix OOTA in general in LKMM.

Best wishes,
   jonas


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ