linux-kernel - Re: [WIP 0/3] Memory model and atomic API in Rust

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: <psy7q3fbnjeyk7fu6wyfecpvgsaxel5vcc6cudftxgyvj4zuhf@3xhjikjjy5pn>
Date: Wed, 27 Mar 2024 17:41:43 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: comex <comexk@...il.com>, "Dr. David Alan Gilbert" <dave@...blig.org>, 
	Philipp Stanner <pstanner@...hat.com>, 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>, Marco Elver <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 Wed, Mar 27, 2024 at 01:45:46PM -0700, Linus Torvalds wrote:
> On Wed, 27 Mar 2024 at 12:41, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
> >
> > _But_: the lack of any aliasing guarantees means that writing through
> > any pointer can invalidate practically anything, and this is a real
> > problem.
> 
> It's actually much less of a problem than you make it out to be.
> 
> A lot of common aliasing information is statically visible (offsets
> off the same struct pointer etc).
> 
> The big problems tend to be
> 
>  (a) old in-order hardware that really wants the compiler to schedule
> memory operations
> 
>  (b) vectorization and HPC

Yeah, I was being a bit dramatic given the current state of the world -
OOO machines _mostly_ do a reasonable job of hiding the negative effects of
this (although not always, when memory barriers are involved).

But I think this is going to become important again in the future, for a
couple reasons.

On the hardware end, the Mill guys were pointing out years ago that
register renaming is a big power bottleneck in modern processors; the
actual functional units consume practically nothing compared to just
moving data around. They never built anything, but there's at least one
new startup I know of that's continuing their work. Yes, VLIW has been a
bust repeatedly, but as we keep going wider and wider (because what else
are we going to do?) I think it's going to happen eventually.

On the compiler side, I'm taking the long view: it's really not just
about a few reloads here and there, it's that you fundamentally can't do
that much with code that's mutating arbitrary state; analysis that
optimizations depend on is impossible. In the compiler you really want
to be working with code that's pure functional - then all your
optimizations are just algebra. And internally, compilers do this as
much as they can (SSA form...), but - unrestricted pointers really put a
limit on what they can do.

The beautiful thing about Rust to me is that we finally might have a
path out of this; the rules of Rust references constrain mutability in
such a way that's almost as good as being purely functional, yet it's
something we can actually do systems programming with.

I think this is going to lead to substantially better code optimization
in the future, and based on a much more sound model that means we won't
constantly be fighting with compiler people because they're doing shady
shit and breaking previously working code. Based on my experiences with
writing iterator heavy code in both C and Rust, I think it already is.