linux-kernel - Re: Allow data races on some read/write operations

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: <ae8ac31f-c6ad-46ae-80dd-10ec081a16d1@ralfj.de>
Date: Tue, 4 Mar 2025 20:03:51 +0100
From: Ralf Jung <post@...fj.de>
To: Boqun Feng <boqun.feng@...il.com>,
 Andreas Hindborg <a.hindborg@...nel.org>
Cc: Alice Ryhl <aliceryhl@...gle.com>,
 Daniel Almeida <daniel.almeida@...labora.com>,
 Benno Lossin <benno.lossin@...ton.me>,
 Abdiel Janulgue <abdiel.janulgue@...il.com>, dakr@...nel.org,
 robin.murphy@....com, rust-for-linux@...r.kernel.org,
 Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
 Gary Guo <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, Trevor Gross <tmgross@...ch.edu>,
 Valentin Obst <kernel@...entinobst.de>, linux-kernel@...r.kernel.org,
 Christoph Hellwig <hch@....de>, Marek Szyprowski <m.szyprowski@...sung.com>,
 airlied@...hat.com, iommu@...ts.linux.dev, comex <comexk@...il.com>,
 lkmm@...ts.linux.dev
Subject: Re: Allow data races on some read/write operations

Hi all,

Ah, the never-ending LKMM vs Rust concurrency story. :)

> In general, this will fall into the exception that we've been given
> from the Rust people. In cases such as this where the Rust language
> does not give us the operation we want, do it like you do in C. Since
> Rust uses LLVM which does not miscompile the C part of the kernel, it
> should not miscompile the Rust part either.

Right, so to be clear this is all a compromise. :)  We don't want Rust to have 
two official memory models. We certainly don't want random Rust programs out 
there experimenting with any non-standard memory models and then expect that to 
work. (They can't all have a Paul McKenny keeping things together. ;) That's why 
in all official docs, you'll only find the one Rust concurrency memory model, 
which is the C++ model.
But meanwhile, the kernel is not some random Rust program out there (and you do 
have Paul ;). The LKMM works quite well in practice, and it is a critical part 
for Rust-for-Linux. Also, we have pretty good contacts with the Rust-for-Linux 
folks, so when there are issues we can just talk.

Given that the LKMM is at the edge (or, arguably, somewhat beyond the edge) of 
what compiler backends can reliably support, I think the lowest-risk strategy is 
to make LKMM usage from Rust look to the compiler just like LKMM usage in C. 
Since it works in C, it should then hopefully also work in Rust. To do this, you 
have to bend (really, break) some of the usual rules for Rust, and that's the 
special exception mentioned above.

>> For cases where we need to do the equivalent of `memmove`/`memcpy`, what
>> are is our options?
>>
> 
> Seems we need "volatile" memmove and memcpy in Rust?

Those already exist in Rust, albeit only unstably: 
<https://doc.rust-lang.org/nightly/std/intrinsics/fn.volatile_copy_memory.html>. 
However, I am not sure how you'd even generate such a call in C? The standard 
memcpy function is not doing volatile accesses, to my knowledge.

Kind regards,
Ralf

>> In case we have no options, do you know who would be the right people on
>> the Rust Project side to contact about getting an exception for this
>> case?
>>
> 
> I will say it'll be t-opsem.
> 
> Regards,
> Boqun
> 
>>
>> Best regards,
>> Andreas Hindborg
>>
>>