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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240322233838.868874-1-boqun.feng@gmail.com>
Date: Fri, 22 Mar 2024 16:38:35 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org,
	llvm@...ts.linux.dev
Cc: Miguel Ojeda <ojeda@...nel.org>,	Alex Gaynor <alex.gaynor@...il.com>,
	Wedson Almeida Filho <wedsonaf@...il.com>,
	Boqun Feng <boqun.feng@...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>,	torvalds@...ux-foundation.org,
	linux-arm-kernel@...ts.infradead.org,	linux-fsdevel@...r.kernel.org
Subject: [WIP 0/3] Memory model and atomic API in Rust

Hi,

Since I see more and more Rust code is comming in, I feel like this
should be sent sooner rather than later, so here is a WIP to open the
discussion and get feedback.

One of the most important questions we need to answer is: which
memory (ordering) model we should use when developing Rust in Linux
kernel, given Rust has its own memory ordering model[1]. I had some
discussion with Rust language community to understand their position
on this:

	https://github.com/rust-lang/unsafe-code-guidelines/issues/348#issuecomment-1218407557
	https://github.com/rust-lang/unsafe-code-guidelines/issues/476#issue-2001382992

My takeaway from these discussions, along with other offline discussion
is that supporting two memory models is challenging for both correctness
reasoning (some one needs to provide a model) and implementation (one
model needs to be aware of the other model). So that's not wise to do
(at least at the beginning). So the most reasonable option to me is:

	we only use LKMM for Rust code in kernel (i.e. avoid using
	Rust's own atomic).

Because kernel developers are more familiar with LKMM and when Rust code
interacts with C code, it has to use the model that C code uses.


And this patchset is the result of that option. I introduced an atomic
library to wrap and implement LKMM atomics (of course, given it's a WIP,
so it's unfinished). Things to notice:

* I know I could use Rust macro to generate the whole set of atomics,
  but I choose not to in the beginning, as I want to make it easier to
  review.

* Very likely, we will only have AtomicI32, AtomicI64 and AtomicUsize
  (i.e no atomic for bool, u8, u16, etc), with limited support for
  atomic load and store on 8/16 bits.

* I choose to re-implement atomics in Rust `asm` because we are still
  figuring out how we can make it easy and maintainable for Rust to call
  a C function _inlinely_ (Gary makes some progress [2]). Otherwise,
  atomic primitives would be function calls, and that can be performance
  bottleneck in a few cases.

* I only have two API implemented and two architecture supported yet,
  the complete support surely can be added when everyone is on the same
  page.


Any suggestion, question, review, help is welcome!

Regards,
Boqun

[1]: https://doc.rust-lang.org/std/sync/atomic/#memory-model-for-atomic-accesses
[2]: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/LTO.20Rust.20modules.20with.20C.20helpers/near/425361365

Boqun Feng (3):
  rust: Introduce atomic module
  rust: atomic: Add ARM64 fetch_add_relaxed()
  rust: atomic: Add fetch_sub_release()

 rust/kernel/sync.rs                   |  1 +
 rust/kernel/sync/atomic.rs            | 65 +++++++++++++++++++++++++++
 rust/kernel/sync/atomic/arch.rs       | 15 +++++++
 rust/kernel/sync/atomic/arch/arm64.rs | 46 +++++++++++++++++++
 rust/kernel/sync/atomic/arch/x86.rs   | 48 ++++++++++++++++++++
 5 files changed, 175 insertions(+)
 create mode 100644 rust/kernel/sync/atomic.rs
 create mode 100644 rust/kernel/sync/atomic/arch.rs
 create mode 100644 rust/kernel/sync/atomic/arch/arm64.rs
 create mode 100644 rust/kernel/sync/atomic/arch/x86.rs

-- 
2.44.0


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ