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: <C85BE4F4-5847-45B4-A973-76B184B35EDE@gmail.com>
Date: Sat, 23 Mar 2024 17:40:23 -0400
From: comex <comexk@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>,
 Boqun Feng <boqun.feng@...il.com>,
 rust-for-linux <rust-for-linux@...r.kernel.org>,
 linux-kernel@...r.kernel.org,
 linux-arch@...r.kernel.org,
 llvm@...ts.linux.dev,
 Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>,
 Wedson Almeida Filho <wedsonaf@...il.com>,
 Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <benno.lossin@...ton.me>,
 Andreas Hindborg <a.hindborg@...sung.com>,
 Alice Ryhl <aliceryhl@...gle.com>,
 Alan Stern <stern@...land.harvard.edu>,
 Andrea Parri <parri.andrea@...il.com>,
 Will Deacon <will@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>,
 Nicholas Piggin <npiggin@...il.com>,
 David Howells <dhowells@...hat.com>,
 Jade Alglave <j.alglave@....ac.uk>,
 Luc Maranget <luc.maranget@...ia.fr>,
 "Paul E. McKenney" <paulmck@...nel.org>,
 Akira Yokosawa <akiyks@...il.com>,
 Daniel Lustig <dlustig@...dia.com>,
 Joel Fernandes <joel@...lfernandes.org>,
 Nathan Chancellor <nathan@...nel.org>,
 Nick Desaulniers <ndesaulniers@...gle.com>,
 kent.overstreet@...il.com,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 elver@...gle.com,
 Mark Rutland <mark.rutland@....com>,
 Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>,
 Catalin Marinas <catalin.marinas@....com>,
 linux-arm-kernel@...ts.infradead.org,
 linux-fsdevel@...r.kernel.org
Subject: Re: [WIP 0/3] Memory model and atomic API in Rust


> On Mar 22, 2024, at 8:12 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> And when the compiler itself is fundamentally buggy, you're kind of
> screwed. When you roll your own, you can work around the bugs in
> compilers.

That may be true, but the LLVM issue you cited isn’t a good example.  In that issue, the function being miscompiled doesn’t actually use any barriers or atomics itself; only the scaffolding around it does.  The same issue would happen even if the scaffolding used LKMM atomics.

For anyone curious: The problematic optimization involves an allocation (‘p’) that is initially private to the function, but is returned at the end of the function.   LLVM moves a non-atomic store to that allocation across an external function call (to ‘foo’).  This reordering would be blatantly invalid if any other code could observe the contents of the allocation, but is valid if the allocation is private to the function.  LLVM assumes the latter: after all, the pointer to it hasn’t escaped.  Yet.  Except that in a weak memory model, the escape can ‘time travel’...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ